[webkit-dev] changelogs: a reprise

[Chris Jerdonek]

I was reading through the old "I HATE CHANGELOGS" messages from August:

https://lists.webkit.org/pipermail/webkit-dev/2009-August/thread.html

The discussion attracted a lot of interest and ideas, but it looks
like it died out without reaching any conclusion.

It seems like the tools around ChangeLogs have improved somewhat since
then, but we still have, for example, the fundamental
conflict-on-commit annoyance.

What do people think about these two possibilities for short- and
mid-term strategies, respectively?

(1) Provide a simple wrapper around "svn commit" and "git svn dcommit"
that encapsulates the retry logic in case of ChangeLog conflicts.
This way, the end-user will never have to resolve ChangeLog conflicts
on commit.  Higher-level commands like webkit-patch could use this
under the hood, if they wanted, to cope with race conditions.

(2) Consider phasing in support for an alternate workflow where new
ChangeLog entries for the next commit are stored separately from the
versioned ChangeLog files -- perhaps in individual .changelog files
for Subversion users and in the commit message for Git users.  The
commands in (1) would be smart enough to read the new ChangeLog
information from these alternate locations, and then add the ChangeLog
information to the ChangeLog files at the last moment -- prior to
commit.  Users of this workflow would never have to resolve ChangeLog
conflicts during the review process, since new entries are stored
separately.  It may be easiest to support this new workflow for Git
users first.

The second idea is essentially Ojan's proposed modification of one of
Maciej's ideas:

https://lists.webkit.org/pipermail/webkit-dev/2009-August/009708.html

It is a mid-term rather than short-term strategy since it involves
changes to several scripts (e.g. svn-create-patch) to allow the review
process to support this alternate workflow.

--Chris