[webkit-dev] ChangeLogs are Deprecated

[Jonathan Bedard via webkit-dev]

As outlined in my email yesterday, Commit-Queue and Merge-Queue both now reject 
any changes that include ChangeLogs.

I will be waiting a few days before actually deleting all of the ChangeLog 
files so that contributors with patches that still contain ChangeLogs can apply 
those patches without conflicts.

Jonathan
WebKit Continuous Integration
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ChangeLogs

[Dirk Pranke]

On Wed, Mar 21, 2012 at 4:18 PM, Timothy Hatcher  wrote:
>
> On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:
>
> I think this is a reasonable suggestion, but I don't agree with it :).
> I would prefer that we try to get good changelogs through culture and
> convention rather than through good tooling.
>
> This is of course based on my experience in my changes and the types
> of changes I review, but I personally find what value there is at all
> in ChangeLogs in the paragraphs at the top of the change, and I find
> the lists of changed files and to be distracting noise far more often
> than not. (Perhaps things are different in changes to the core
> rendering code than changes to tooling and test code).
>
>
> I find the comments useful, even for scripts. ChangeLogs for tests are often
> more mundane.
>

I should clarify that I do find value in describing the why of the
change, so I could agree w/ Maciej that requiring *something* more
than the subject + bug + reviewer might be justified for changes. Just
linking to a bug would be overly terse.

My annoyance with ChangeLogs stems from just integrating them into my
workflow (which often involves multiple pipelined changes and/or lots
of merging and rebasing), but that's off-topic for this thread. I am
also sometimes annoyed by ChangeLogs when a change happens to span
multiple ChangeLogs and I either have to repeat myself or figure out
how to split my description between the files, which is slightly more
on-topic.

Mostly I just don't want there to be a lot of boilerplate or noise in
the ChangeLogs.

-- Dirk

> My particular interest is the Web Inspector, which I follow by watching bugs
> and commits. Often I find myself asking "why?" or "what does this do?" when
> perusing the commits. It sometimes isn't very obvious and a nice concise
> description in the ChangeLog would help. This is even more important when
> folks are separated by timezones or are not easy to reach for explanation.
>
> They also provide insight when looking back on changes from months or years
> ago when tracking down a regression.
>
> I think it is difficult to say what a "good" changelog is an any sort
> of algorithmic sense, and trying to implement something that would be
> done programmatically will be more annoying than useful (even if it
> means that I just have to delete a bunch of "OOPS" lines).
>
>
> It would be difficult to make the tool smart. I merely looking for reminder
> to push folks to describe their changes in some fashion, not a analytical
> tool parsing for good vs bad.
>
> — Timothy Hatcher
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Timothy Hatcher]

On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:

> I think this is a reasonable suggestion, but I don't agree with it :).
> I would prefer that we try to get good changelogs through culture and
> convention rather than through good tooling.
> 
> This is of course based on my experience in my changes and the types
> of changes I review, but I personally find what value there is at all
> in ChangeLogs in the paragraphs at the top of the change, and I find
> the lists of changed files and to be distracting noise far more often
> than not. (Perhaps things are different in changes to the core
> rendering code than changes to tooling and test code).

I find the comments useful, even for scripts. ChangeLogs for tests are often 
more mundane.

My particular interest is the Web Inspector, which I follow by watching bugs 
and commits. Often I find myself asking "why?" or "what does this do?" when 
perusing the commits. It sometimes isn't very obvious and a nice concise 
description in the ChangeLog would help. This is even more important when folks 
are separated by timezones or are not easy to reach for explanation.

They also provide insight when looking back on changes from months or years ago 
when tracking down a regression.

> I think it is difficult to say what a "good" changelog is an any sort
> of algorithmic sense, and trying to implement something that would be
> done programmatically will be more annoying than useful (even if it
> means that I just have to delete a bunch of "OOPS" lines).


It would be difficult to make the tool smart. I merely looking for reminder to 
push folks to describe their changes in some fashion, not a analytical tool 
parsing for good vs bad.

— Timothy Hatcher

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Maciej Stachowiak]

On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:

> On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak  wrote:
>> 
>> On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
>> 
>> Lately I have observed more and more and more changes going into WebKit that
>> lack any details about why a particular change was made. It is intended that
>> the ChangeLog (and commit message) contain some details about your change,
>> not just the bug title and URL.
>> 
>> The contributing information on subject is pretty sparse, which has likely
>> caused this problem to manifest. However, the example ChangeLog linked from
>> that page is prime example of what we all should strive for when describing
>> our changes.
>> 
>> To help curb this lack of detail in ChangeLogs, I propose we add script (or
>> augment an existing script) to check for this missing information and inform
>> the contributor. It is clear not all reviewers are asking patch authors to
>> provide this information when reviewing, and such a tool would help enforce
>> it.
>> 
>> 
>> I think this is a reasonable suggestion. I think we should make the
>> contributor docs more clear about what is expected, as well.
>> 
> 
> I think this is a reasonable suggestion, but I don't agree with it :).
> I would prefer that we try to get good changelogs through culture and
> convention rather than through good tooling.
> 
> This is of course based on my experience in my changes and the types
> of changes I review, but I personally find what value there is at all
> in ChangeLogs in the paragraphs at the top of the change, and I find
> the lists of changed files and to be distracting noise far more often
> than not. (Perhaps things are different in changes to the core
> rendering code than changes to tooling and test code).

I agree that setting the right conventions, and getting agreement on this, is 
the most important step. I think the ChangeLogs that are most worrisome are the 
ones that do not even have an explanatory paragraph at the top, just a bug URL 
and title. It can be hard to understand the 

I often really appreciate ChangeLogs with file-by-file or even 
function-by-function explanations, but I wouldn't say that is the bare minimum 
required for all changes. For simple changes, a short paragraph above may be 
totally sufficient. It is very rare that just the bug URL and title are 
sufficient, though.

Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Adam Barth]

On Wed, Mar 21, 2012 at 3:45 PM, Timothy Hatcher  wrote:
> On Mar 21, 2012, at 2:46 PM, Adam Barth wrote:
>> On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher  wrote:
>>> Lately I have observed more and more and more changes going into WebKit that
>>> lack any details about why a particular change was made. It is intended that
>>> the ChangeLog (and commit message) contain some details about your change,
>>> not just the bug title and URL.
>>
>> Since I was the reviewer for 
>> (although if you look in the bug thread, you'll see that I was just
>> forwarding fishd's R+ after some trivial cleanups), I'm curious what
>> additional information you think should have been included in that
>> ChangeLog.
>>
>> There really isn't much to say about that change.  Tommy was just
>> adding thin API wrappers around WebCore objects as part of the
>> implementation of the MediaStream API.  The main point of discussion
>> in the bug thread was whether to use the name ICE or Ice.
>
> "Adding thin API wrappers around WebCore objects as part of the 
> implementation of the MediaStream API." would be a good start. I shouldn't 
> have to troll through a bug with 21 comments to figure out a change. Also the 
> WebCore changes are just case changes, but you wouldn't know that by just 
> perusing the ChangeLog/commit message.

Yeah, I definitely find ChangeLog messages useful for filtering which
changes to dig into in more detail (e.g., when hunting for a
regression).  Thanks!

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Timothy Hatcher]

On Mar 21, 2012, at 2:46 PM, Adam Barth wrote:

> On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher  wrote:
>> Lately I have observed more and more and more changes going into WebKit that
>> lack any details about why a particular change was made. It is intended that
>> the ChangeLog (and commit message) contain some details about your change,
>> not just the bug title and URL.
> 
> Since I was the reviewer for 
> (although if you look in the bug thread, you'll see that I was just
> forwarding fishd's R+ after some trivial cleanups), I'm curious what
> additional information you think should have been included in that
> ChangeLog.
> 
> There really isn't much to say about that change.  Tommy was just
> adding thin API wrappers around WebCore objects as part of the
> implementation of the MediaStream API.  The main point of discussion
> in the bug thread was whether to use the name ICE or Ice.
> 
> Adam


"Adding thin API wrappers around WebCore objects as part of the implementation 
of the MediaStream API." would be a good start. I shouldn't have to troll 
through a bug with 21 comments to figure out a change. Also the WebCore changes 
are just case changes, but you wouldn't know that by just perusing the 
ChangeLog/commit message.

— Timothy Hatcher


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Dirk Pranke]

On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak  wrote:
>
> On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
>
> Lately I have observed more and more and more changes going into WebKit that
> lack any details about why a particular change was made. It is intended that
> the ChangeLog (and commit message) contain some details about your change,
> not just the bug title and URL.
>
> The contributing information on subject is pretty sparse, which has likely
> caused this problem to manifest. However, the example ChangeLog linked from
> that page is prime example of what we all should strive for when describing
> our changes.
>
> To help curb this lack of detail in ChangeLogs, I propose we add script (or
> augment an existing script) to check for this missing information and inform
> the contributor. It is clear not all reviewers are asking patch authors to
> provide this information when reviewing, and such a tool would help enforce
> it.
>
>
> I think this is a reasonable suggestion. I think we should make the
> contributor docs more clear about what is expected, as well.
>

I think this is a reasonable suggestion, but I don't agree with it :).
I would prefer that we try to get good changelogs through culture and
convention rather than through good tooling.

This is of course based on my experience in my changes and the types
of changes I review, but I personally find what value there is at all
in ChangeLogs in the paragraphs at the top of the change, and I find
the lists of changed files and to be distracting noise far more often
than not. (Perhaps things are different in changes to the core
rendering code than changes to tooling and test code).

I think it is difficult to say what a "good" changelog is an any sort
of algorithmic sense, and trying to implement something that would be
done programmatically will be more annoying than useful (even if it
means that I just have to delete a bunch of "OOPS" lines).

-- Dirk

> Regards,
> Maciej
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Ryosuke Niwa]

On Wed, Mar 21, 2012 at 2:41 PM, David Levin  wrote:

> I think the challenge in part is to explain why the ChangeLog is useful.
>
> Comments in there hopefully explain why as a guide to reviewers to give
> the reviewers and future onlookers a guide to the change.
>

I do agree that "why" comments are more useful than "what" comments are
most cases.

However, I'd say it's also helpful to summarize what a new function / class
does as well if the patch adds one. Since comments in the change log is for
a specific revision unlike comments in the code, it's less dangerous to add
"what" comment.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Adam Barth]

On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher  wrote:
> Lately I have observed more and more and more changes going into WebKit that
> lack any details about why a particular change was made. It is intended that
> the ChangeLog (and commit message) contain some details about your change,
> not just the bug title and URL.

Since I was the reviewer for 
(although if you look in the bug thread, you'll see that I was just
forwarding fishd's R+ after some trivial cleanups), I'm curious what
additional information you think should have been included in that
ChangeLog.

There really isn't much to say about that change.  Tommy was just
adding thin API wrappers around WebCore objects as part of the
implementation of the MediaStream API.  The main point of discussion
in the bug thread was whether to use the name ICE or Ice.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[David Levin]

I think the challenge in part is to explain why the ChangeLog is useful.

Comments in there hopefully explain why as a guide to reviewers to give the
reviewers and future onlookers a guide to the change.

It feels like what comments are that useful but often get inserted in there
to fill it out. Is there a good way to address this? (Should folks just
leave what comments out or put in the obvious what?)

Since we have an example ChangeLog, I'll point out what I mean using it
(but it is evident in many ChangeLog's from me as well).

What value does this comment add?

   - runtime/JSGlobalData.h: Replaced the HashSet and HashCountedSet with a
   Vector.

On the other hand, I found this very informative:

wtf/PassRefPtr.h:
(WTF::PassRefPtr::~PassRefPtr): The most common thing to do with a
PassRefPtr in hot code is to pass it and then destroy it once it's
set to zero. Help the optimizer by telling it that's true.




Here again, we see a what comment:

parser/Nodes.cpp:
(JSC::NodeReleaser::releaseAllNodes): ALWAYS_INLINE.
(JSC::NodeReleaser::adopt): Ditto.

Which doesn't tell me why ALWAYS_INLINE was added (which I can easily see
from the patch).

dave

On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak  wrote:

>
> On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
>
> Lately I have observed more  and
> more  and 
> more changes
> going into WebKit that lack any details about why a particular change was
> made. It is intended that the ChangeLog (and commit message) contain some
> details about your change, not just the bug title and URL.
>
> The contributing 
> information on
> subject is pretty sparse, which has likely caused this problem to manifest.
> However, the example ChangeLog  linked
> from that page is prime example of what we all should strive for when
> describing our changes.
>
> To help curb this lack of detail in ChangeLogs, I propose we add 
> script (or
> augment an existing script) to check for this missing information and
> inform the contributor. It is clear not all reviewers are asking patch
> authors to provide this information when reviewing, and such a tool would
> help enforce it.
>
>
> I think this is a reasonable suggestion. I think we should make the
> contributor docs more clear about what is expected, as well.
>
> Regards,
> Maciej
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Konrad Piascik]

There are some changes which have bug descriptions which are complete enough to 
not need additional comments and any changes to existing scripts should keep 
this in mind. One way to do this is to check for the number of lines/files the 
diff has.
Konrad
Sent from my BlackBerry on the Rogers Wireless Network

From: Timothy Hatcher [mailto:timo...@apple.com]
Sent: Wednesday, March 21, 2012 05:29 PM
To: webkit-dev@lists.webkit.org 
Subject: [webkit-dev] ChangeLogs

Lately I have observed more<http://trac.webkit.org/changeset/111595> and 
more<http://trac.webkit.org/changeset/111577> and 
more<http://trac.webkit.org/changeset/111527> changes going into WebKit that 
lack any details about why a particular change was made. It is intended that 
the ChangeLog (and commit message) contain some details about your change, not 
just the bug title and URL.

The contributing 
information<http://www.webkit.org/coding/contributing.html#changelogs> on 
subject is pretty sparse, which has likely caused this problem to manifest. 
However, the example ChangeLog<http://trac.webkit.org/changeset/43259> linked 
from that page is prime example of what we all should strive for when 
describing our changes.

To help curb this lack of detail in ChangeLogs, I propose we add 
script<https://bugs.webkit.org/show_bug.cgi?id=81828> (or augment an existing 
script) to check for this missing information and inform the contributor. It is 
clear not all reviewers are asking patch authors to provide this information 
when reviewing, and such a tool would help enforce it.

— Timothy Hatcher


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Maciej Stachowiak]

On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:

> Lately I have observed more and more and more changes going into WebKit that 
> lack any details about why a particular change was made. It is intended that 
> the ChangeLog (and commit message) contain some details about your change, 
> not just the bug title and URL.
> 
> The contributing information on subject is pretty sparse, which has likely 
> caused this problem to manifest. However, the example ChangeLog linked from 
> that page is prime example of what we all should strive for when describing 
> our changes.
> 
> To help curb this lack of detail in ChangeLogs, I propose we add script (or 
> augment an existing script) to check for this missing information and inform 
> the contributor. It is clear not all reviewers are asking patch authors to 
> provide this information when reviewing, and such a tool would help enforce 
> it.

I think this is a reasonable suggestion. I think we should make the contributor 
docs more clear about what is expected, as well.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] ChangeLogs

[Timothy Hatcher]

Lately I have observed more and more and more changes going into WebKit that 
lack any details about why a particular change was made. It is intended that 
the ChangeLog (and commit message) contain some details about your change, not 
just the bug title and URL.

The contributing information on subject is pretty sparse, which has likely 
caused this problem to manifest. However, the example ChangeLog linked from 
that page is prime example of what we all should strive for when describing our 
changes.

To help curb this lack of detail in ChangeLogs, I propose we add script (or 
augment an existing script) to check for this missing information and inform 
the contributor. It is clear not all reviewers are asking patch authors to 
provide this information when reviewing, and such a tool would help enforce it.

— Timothy Hatcher

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[David Kilzer]

On Thu, January 28, 2010 at 4:10:11 AM, Chris Jerdonek wrote:


> On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer wrote:
> >> (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.
> 
> > I'm not a big fan of wrapper scripts, mostly because I'll probably
> > forget about using them since I'm so used to using the basic
> > git/svn commands.  (I guess svn-create-patch is a counter-argument
> > to that, but I rarely use svn directly anymore.)
> >
> > Using .changelog-bugnum files should probably be optional if it's
> > implemented, e.g., tools should still be smart enough (or at least
> > as smart as they are today) to operate on ChangeLog files directly
> > if developers choose to continue doing that.  I say that because
> > once there is a git merge driver for ChangeLog files, the need for
> > an alternative ChangeLog workflow drops to zero, at least for me.
> 
> I ran into an issue today where "git diff" didn't generate me a patch
> with the ChangeLog portion in the standard format.  Namely, the
> ChangeLog diff had non-empty leading context (which can happen since
> it doesn't run fixChangeLogPatch like the svn-create-patch wrapper
> script).  Is there a way to address this issue for Git users without
> using wrapper scripts or a change to the ChangeLog workflow?


I'm not sure if there is a way to "fix up" patches when they're created using 
git-diff, e.g., some kind of diff hook.  Note that there is no "loss of 
information" if a ChangeLog patch isn't fixed up immediately after it's 
created, so the fix-up can always happen when the patch is applied later.  It 
just looks a little ugly in the meantime.  :)

I also replied with more thoughts in Bug 32834.



Dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[Chris Jerdonek]

On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer  wrote:
>> (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.

> I'm not a big fan of wrapper scripts, mostly because I'll probably forget 
> about using them since I'm so used to using the basic git/svn commands.  (I 
> guess svn-create-patch is a counter-argument to that, but I rarely use svn 
> directly anymore.)
>
> Using .changelog-bugnum files should probably be optional if it's 
> implemented, e.g., tools should still be smart enough (or at least as smart 
> as they are today) to operate on ChangeLog files directly if developers 
> choose to continue doing that.  I say that because once there is a git merge 
> driver for ChangeLog files, the need for an alternative ChangeLog workflow 
> drops to zero, at least for me.

I ran into an issue today where "git diff" didn't generate me a patch
with the ChangeLog portion in the standard format.  Namely, the
ChangeLog diff had non-empty leading context (which can happen since
it doesn't run fixChangeLogPatch like the svn-create-patch wrapper
script).  Is there a way to address this issue for Git users without
using wrapper scripts or a change to the ChangeLog workflow?

--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[Tor Arne Vestbø]

Tor Arne Vestbø wrote:
Here's a wip patch to update-webkit's Git part I've been running locally 
for a few days now, it has basic resolve-ChangeLogs-support, as well as 
mirror support:


http://gist.github.com/287646


https://bugs.webkit.org/show_bug.cgi?id=34206

tor arne

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[Tor Arne Vestbø]

David Levin wrote:

I think someone already wrote this for you:
  http://ivanz.com/2009/03/19/git-automatic-smart-changelog-merging/
which referrs to 
  http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c;h=b9ab42947b2590b31d69544d566e1f6b04a90100;hb=HEAD


A merge-driver would be cool.

Here's a wip patch to update-webkit's Git part I've been running locally 
for a few days now, it has basic resolve-ChangeLogs-support, as well as 
mirror support:


http://gist.github.com/287646

It might help a little bit on the way to a more non-wrapped future.

tor arne

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[Eric Seidel]

Soon after that I wrote bugzilla-tool (now called webkit-patch).  Adam
Barth and I learned that webkit-patch made it easy to just "save"
patches to bugs, using post and apply-attachment.  That was easier
than bothering with branches in many cases (at least branches
containing ChangeLogs).

It's even easier for me to avoid storing changelogs now that "upload"
prompts me to write them when I finally do post the patch.

On Tue, Jan 26, 2010 at 10:19 AM, Chris Jerdonek  wrote:
> On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer  wrote:
>>
>> I think I mentioned this before, but for git users, this can be solved in 
>> the short term by a merge driver that uses resolve-ChangeLogs (once it knows 
>> how to be invoked by git as a merge driver):
>
> This seems like a good idea.
>
>> I started hacking on resolve-ChangeLogs to be invoked by three arguments 
>> this way, but haven't had time to finish it.
>
> I came across this report:
>
> https://bugs.webkit.org/show_bug.cgi?id=28721
>
> "I looked briefly at writing this today.  The merge driver is passed paths to 
> 3
> temp files.  1. previous version 2. other branch version.  3.  this branch
> version.  Maybe one of the other WebKit git users will get further than I 
> did."
>
> Looks like you and Eric might want to connect. ;)
>
> --Chris
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[Chris Jerdonek]

On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer  wrote:
>
> I think I mentioned this before, but for git users, this can be solved in the 
> short term by a merge driver that uses resolve-ChangeLogs (once it knows how 
> to be invoked by git as a merge driver):

This seems like a good idea.

> I started hacking on resolve-ChangeLogs to be invoked by three arguments this 
> way, but haven't had time to finish it.

I came across this report:

https://bugs.webkit.org/show_bug.cgi?id=28721

"I looked briefly at writing this today.  The merge driver is passed paths to 3
temp files.  1. previous version 2. other branch version.  3.  this branch
version.  Maybe one of the other WebKit git users will get further than I did."

Looks like you and Eric might want to connect. ;)

--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[David Levin]

I think someone already wrote this for you:
  http://ivanz.com/2009/03/19/git-automatic-smart-changelog-merging/
which referrs to

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c;h=b9ab42947b2590b31d69544d566e1f6b04a90100;hb=HEAD

I was using this for a while and it seemed to work well when you do git
rebase. If you do a merge, your changelog entry will end up after the merged
changelog entries which makes sense but isn't what I wanted typically.

dave

PS I only stopped out of laziness. Setting this up vs typing
resolve-ChangeLog --continue (which isn't that big of a deal for me).


On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer  wrote:

> On Mon, January 25, 2010 at 10:35:00 PM, Chris Jerdonek 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.
>
>
> I think I mentioned this before, but for git users, this can be solved in
> the short term by a merge driver that uses resolve-ChangeLogs (once it knows
> how to be invoked by git as a merge driver):
>
> <
> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers
> >
>
> I started hacking on resolve-ChangeLogs to be invoked by three arguments
> this way, but haven't had time to finish it.
>
> I'm not a big fan of wrapper scripts, mostly because I'll probably forget
> about using them since I'm so used to using the basic git/svn commands.  (I
> guess svn-create-patch is a counter-argument to that, but I rarely use svn
> directly anymore.)
>
> Using .changelog-bugnum files should probably be optional if it's
> implemented, e.g., tools should still be smart enough (or at least as smart
> as they are today) to operate on ChangeLog files directly if developers
> choose to continue doing that.  I say that because once there is a git merge
> driver for ChangeLog files, the need for an alternative ChangeLog workflow
> drops to zero, at least for me.
>
> Dave
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[David Kilzer]

On Mon, January 25, 2010 at 10:35:00 PM, Chris Jerdonek 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.


I think I mentioned this before, but for git users, this can be solved in the 
short term by a merge driver that uses resolve-ChangeLogs (once it knows how to 
be invoked by git as a merge driver):



I started hacking on resolve-ChangeLogs to be invoked by three arguments this 
way, but haven't had time to finish it.

I'm not a big fan of wrapper scripts, mostly because I'll probably forget about 
using them since I'm so used to using the basic git/svn commands.  (I guess 
svn-create-patch is a counter-argument to that, but I rarely use svn directly 
anymore.)

Using .changelog-bugnum files should probably be optional if it's implemented, 
e.g., tools should still be smart enough (or at least as smart as they are 
today) to operate on ChangeLog files directly if developers choose to continue 
doing that.  I say that because once there is a git merge driver for ChangeLog 
files, the need for an alternative ChangeLog workflow drops to zero, at least 
for me.

Dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[Maciej Stachowiak]

On Jan 25, 2010, at 10:39 PM, Eric Seidel wrote:

> On Mon, Jan 25, 2010 at 10:38 PM, Eric Seidel  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!

The check could be as simple as updating ChangeLog and then running 
resolve-ChangeLog-conflicts.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelogs: a reprise

[Eric Seidel]

On Mon, Jan 25, 2010 at 10:38 PM, Eric Seidel  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  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@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev