[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] I *HATE* CHANGELOGS!!!
From: Jeremy Orlow <jorlow () chromium ! org>
Date: 2009-08-28 20:05:57
Message-ID: 5dd9e5c50908281305o783888cay35ffbe7fc099efa1 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson <beidson@apple.com> wrote:
>
> On Aug 28, 2009, at 12:18 PM, George Staikos wrote:
>
>
> On 26-Aug-09, at 2:44 PM, Maciej Stachowiak wrote:
>
>
> On Aug 26, 2009, at 5:38 PM, Geoffrey Garen wrote:
>
>
> Detailed descriptions, bug links, test instructions, and a link back to the
> entire original review history are all part of Chromium commits, yet we
> don't use ChangeLogs. I think discipline about what to include + tooling to
> support it are orthogonal to a project's use of a ChangeLog as the mechanism
> for conveying this information.
>
>
> [This question not necessarily just for Peter:]
>
>
> If we removed the discipline of reviewing ChangeLogs, and the tools that
> autogenerate a ChangeLog template and check for a ChangeLog entry without an
> "OOPs I didn't get this reviewed" message, what would we replace them with?
>
>
> I can imagine a discipline where we ensure that pending commit entries sit
> in a designated file in your tree, are made by a tool much like
> prepare-ChangeLog, are included in patches by svn-create-patch, are applied
> by svn-apply-patch, and are used by commit-log-editor. That would ensure the
> entries go through the patch life cycle just as much as currently.
>
>
> Another possibility is to have a review site (bugzilla?) be the canonical
> place for log entries until they get committed. At commit time, a tool would
> pull from this location.
>
>
>
> I want to add a +1 for the "hate changelogs" group. I have been
> advocating this for about 4 years now. It's much more painful when on a
> remote, slow link. Is it really a problem to generate the ChangeLog files
> from the svn commit messages on a daily or weekly basis? There are scripts
> for this.
>
>
> This is an interesting idea.
>
> Mark Rowe already pointed out - doing an automated step for each checkin
> that causes another checkin would be ridiculous. But how about a nightly
> script that checks in a ChangeLog accounting for the day's commits?
>
> Seems reasonable to me. +1
>
+1
Agreed. If it's done daily, Trac would be a good way to look at what's
happened very recently.
[Attachment #5 (text/html)]
<div class="gmail_quote">On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson <span \
dir="ltr"><<a href="mailto:beidson@apple.com">beidson@apple.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Aug 28, 2009, at \
12:18 PM, George Staikos wrote:</div><br><blockquote type="cite"><div><br>On \
26-Aug-09, at 2:44 PM, Maciej Stachowiak wrote:<br><br><blockquote type="cite">
<br></blockquote><blockquote type="cite">On Aug 26, 2009, at 5:38 PM, Geoffrey Garen \
wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote \
type="cite"><blockquote type="cite"><blockquote type="cite">
Detailed descriptions, bug links, test instructions, and a link back to the entire \
original review history are all part of Chromium commits, yet we don't use \
ChangeLogs. I think discipline about what to include + tooling to support it are \
orthogonal to a project's use of a ChangeLog as the mechanism for conveying this \
information.<br>
</blockquote></blockquote></blockquote><blockquote type="cite"><blockquote \
type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote \
type="cite">[This question not necessarily just for Peter:]<br></blockquote>
</blockquote><blockquote type="cite"><blockquote \
type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote \
type="cite">If we removed the discipline of reviewing ChangeLogs, and the tools that \
autogenerate a ChangeLog template and check for a ChangeLog entry without an \
"OOPs I didn't get this reviewed" message, what would we replace them \
with?<br>
</blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote \
type="cite">I can imagine a discipline where we ensure that pending commit entries \
sit in a designated file in your tree, are made by a tool much like \
prepare-ChangeLog, are included in patches by svn-create-patch, are applied by \
svn-apply-patch, and are used by commit-log-editor. That would ensure the entries go \
through the patch life cycle just as much as currently.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Another \
possibility is to have a review site (bugzilla?) be the canonical place for log \
entries until they get committed. At commit time, a tool would pull from this \
location.<br>
</blockquote><br><br> I want to add a +1 for the "hate changelogs" group. \
I have been advocating this for about 4 years now. It's much more painful when \
on a remote, slow link. Is it really a problem to generate the ChangeLog files from \
the svn commit messages on a daily or weekly basis? There are scripts for this.<font \
color="#000000"><font color="#144FAE"><br>
</font></font></div></blockquote><div><br></div></div><div>This is an interesting \
idea.</div><div><br></div><div>Mark Rowe already pointed out - doing an automated \
step for each checkin that causes another checkin would be ridiculous. But how about \
a nightly script that checks in a ChangeLog accounting for the day's \
commits?</div>
<div><br></div><div>Seems reasonable to me. \
+1</div></div></div></blockquote><div><br></div><div>+1</div><div><br></div><div>Agreed. \
If it's done daily, Trac would be a good way to look at what's happened very \
recently.</div>
</div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic