[webkit-dev] changelogs: a reprise

[Eric Seidel]

On Mon, Jan 25, 2010 at 10:38 PM, Eric Seidel <eseidel at google.com> wrote:
> Re: #1 I strongly support a wrapper around commit.  That's what
> "webkit-patch land" is supposed to be.  It allows us to do all sorts
> of pre-commit checks!
>
> Re: #2 I think .changelog files could be cool, but they would need to
> be .changelog-bugnum in order to allow working on multiple changes, at
> least for svn users.
>
> -eric
>
>
>
> On Mon, Jan 25, 2010 at 10:35 PM, Chris Jerdonek <cjerdonek at webkit.org> wrote:
>> 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
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>