[webkit-dev] Changes to prepare-ChangeLog

[John Abd-El-Malek]

The workflow I'm looking for is something like svn/perforce changelists.
 That way I could have multiple unrelated changes coexisting in the same
checkout.
An example of this is what we use on Chromium: gcl.py (see the latest
version at
http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/gcl.py?view=markup).
 It allows you to create a changelist and associate a description and a list
of files/directory changes with it).  The basic usage is that "gcl
change CHANGENAME" pops up a text file in the default editor where a
description can be entered.  By moving filenames from two sections below it,
the developer controls which modified files are in this changelist.
 Operations such as "gcl upload CHANGENAME" (upload to Rietveld) work on the
group of files at the same time (also things like gcl
diff/commit/revert).  The nice thing about it that on such large codebases,
developers will often have unrelated changes, and this avoids having to
unapply/apply frequently.

On Fri, Jul 10, 2009 at 5:57 PM, David Kilzer <ddkilzer at webkit.org> wrote:

> Quilt?  <http://savannah.nongnu.org/projects/quilt>
>
> What workflow are you trying to accomplish?  I'm not sure I understand what
> a "changelist" is in this context and how bugzilla-tool would support them.
>
> Dave
>
>
>
> *From:* John Abd-El-Malek <jam at google.com>
> *To:* Ojan Vafai <ojan at chromium.org>
> *Cc:* WebKit Development <webkit-dev at lists.webkit.org>; Mark Rowe <
> mrowe at apple.com>
> *Sent:* Friday, July 10, 2009 5:11:53 PM
> *Subject:* Re: [webkit-dev] Changes to prepare-ChangeLog
>
> To add another tangent to this thread: one thing I don't like about
> ChangeLog files is that they make it impossible to have multiple concurrent
> changes in the same checkout.  Yes I know that some people use git to get
> around this, while others use the svn-apply/svn-unapply scripts.  But I feel
> these are just workarounds to get around limitations of the current tools.
>  We should fix the tools instead.  If we don't require to change one central
> file for each change, then bugzilla-tool can be modified to support
> changelists.
>
> On Thu, Jul 9, 2009 at 1:45 PM, Ojan Vafai <ojan at chromium.org> wrote:
>
>> While having consistency in changelog descriptions is nice, I'm not sure
>> we need to explicitly deal with the case of having multiple authors or
>> multiple bugs for a change. Those are rare enough situations that it's fine
>> for people to include that information however they want.
>> Or, if you don't agree with me, we can at least make those a separate
>> discussion. It would be nice if this discussion could focus on what goes in
>> the default text of a changelog description.
>>
>> The original goal here was to reduce the number of patches that get r-'ed
>> for unnecessary changelog errors. Multiple authors rarely, if ever, results
>> in an r-. Similarly, multiple bugs is rarely an issue for new contributors.
>>
>> Ojan
>>
>> On Thu, Jul 9, 2009 at 1:30 PM, Mark Rowe <mrowe at apple.com> wrote:
>>
>>>
>>> On 2009-07-09, at 08:02, Joe Mason wrote:
>>>
>>>  Maciej Stachowiak wrote:
>>>>
>>>>> Now that my attention has been called to it, it's starting to bug me
>>>>> that everyone formats their ChangeLog entries slightly differently. How
>>>>> about this as the canonical format (with prepare-ChangeLog encouraging it)?
>>>>>
>>>>
>>>> That reminds me: how do we format a patch with multiple authors?  I've
>>>> been doing this:
>>>>
>>>>  2009-07-08  Maciej Stachowiak  <mjs at apple.com>
>>>>>       Make prepare-ChangeLog less shouty
>>>>>       https://bugs.webkit.org/show_bug.cgi?id=27098
>>>>>
>>>> >         Authors: Maciej Stachowiak <mjs at apple.com>, Joe Mason <
>>>> joe.mason at torchmobile.com>
>>>>
>>>>>       Reviewed by Mark Rowe.
>>>>>       * Scripts/prepare-ChangeLog:
>>>>>
>>>>
>>>> So, the main author (or whichever one is submitting the patch if that's
>>>> unclear) in the header, then a separate "Authors" line above the Reviewer
>>>> line with everyone who deserves credit.
>>>>
>>>
>>> I've never seen this format used in WebKit patches.
>>>
>>> - Mark
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090710/6b6537e2/attachment.html>