[webkit-dev] Changes to prepare-ChangeLog

Maciej Stachowiak mjs at apple.com
Fri Jul 3 14:19:51 PDT 2009

On Jul 3, 2009, at 10:44 AM, Jeremy Orlow wrote:

> On Fri, Jul 3, 2009 at 10:24 AM, Peter Kasting <pkasting at google.com>  
> wrote:
> Since this seems to have become the new bikeshed, I'll chime in with  
> my color preference:
> ----
> Reviewed by John Smith (jsmith at webkit.org)
> https://bugs.webkit.org/show_bug.cgi?id=123456
> Fix WebKit being not awesome enough.  Make five files more awesome.
> ----
> FWIW, I agree with those who desire to ditch the ChangeLog.  WebKit  
> is the only project I've worked on that does such a thing, and I  
> have never gotten any benefit out of it, while I've gotten lots of  
> headache (merge conflicts especially).  On Chromium, patches are  
> given a detailed ChangeLog-esque description which is visible in the  
> review tool and becomes the commit log message as well (which links  
> back to the review URL, and is also auto-pasted into the original  
> bug report).  This way from any of (bug system, commit logs, review  
> system) you can find information about a particular patch or search  
> for patches matching some comment.  This turns out to work quite  
> well in practice.  In WebKit I try to give my patches these sorts of  
> comments when I post them for review, but duplicating info between  
> the ChangeLog and the review comments always makes me write less  
> than I otherwise would, and review comments tend to get buried in  
> the sea of noise from bugzilla.
> I agree that the ChangeLog really is duplicate information and  
> generally a pain to update.
> I know that there are some people who really like them.  Why not  
> fill them in automatically?  Just have a tool that once a night/hour/ 
> checkin generates entries for the new checkins and puts it somewhere  
> on the web or checks it in.

What I do (and I think many of us do) is use a script that  
automatically fills in the commit message from the ChangeLog. I'm not  
sure why it would be better to copy from the commit messages to the  
ChangeLog instead of vice versa, or to do it as a separate step  
instead of at commit time. Are the people who find it a pain to update  
copying by hand or something? For people who use git, who have  
presumably already committed their patches locally before posting for  
review, I think it's fine to do it the other way around and generate  
the ChangeLog from the commit message when pushing the change back to  
the master repository. I don't think it's necessary to maintain  
ChangeLog in your private change branches. I would expect git users to  
have made tools for dealing with this. For people who use SVN  
directly, though there's no other place for our tools to pull the log  
message, so things like "bugzilla-tool post-diff XXXX" could not  
properly post your diff with a log entry, commit scripts wouldn't be  
able to fill in the log message that you've already had reviewed, etc.

> I know one of the concerns was reviews.  What I do anyway is copy  
> the ChangeLog description into the optional long description field  
> when posting the patch, why not do that?  Maybe it'd even be easy to  
> display that somewhere on the review UI, but otherwise it seems fine  
> to just open the review in another tab in case you need to refer  
> back to it.
> It seems like the ChangeLog is just a work-around for a lack of  
> tools.  And it seems like it wouldn't be too hard to make the tools  
> we've got better.  (And yes, I'll even help out if that's the  
> direction everyone chooses to take.  :-)

ChangeLog is in part just a tradition - all GNU projects do it, and  
for a while many free software projects were doing it. I personally  
search ChangeLog for information fairly often and I don't think the  
commit logs or bug tracker would be equally convenient since they are  
not available in time-ordered plaintext form.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090703/fdbb2e0f/attachment.html>

More information about the webkit-dev mailing list