On Jul 3, 2009, at 10:44 AM, Jeremy Orlow wrote:
On Fri, Jul 3, 2009 at 10:24 AM, Peter Kasting <pkast...@google.com>
wrote:
Since this seems to have become the new bikeshed, I'll chime in with
my color preference:
----
Reviewed by John Smith (jsm...@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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
