Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Ryosuke Niwa
On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos 
 carlo...@webkit.org wrote:

 El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió:
  Hi,

 [...]
 
  Separately, I'd like to know whether people liked the new format and
  it's worth my time making webkitpy adopt the new format.

 I prefer the old format.

 
  I personally didn't like the old format because it made the first line
  of each change log too long.  I'm also not a big fun of wrapping URLs
  in angle brackets.  It's also unclear to me what should happen when
  there are multiple Bugzilla URLs to list.
 
 
  But I hear the new format made git log --oneline much more readable so
  I can be convinced although I don't intend to use git for WebKit
  development in the foreseeable future myself.

 Well, git log is not actually affected by the ChangeLog format, but by
 the commit message. I mean, we generate the commit message from the
 ChangeLog, so we can keep the old format in the ChangeLog and update the
 script to generate the commit message to make it better for oneline git
 log format. webkitpy parses the ChangeLog not the commit message, so
 everything should work.


 If I'm not mistaken, I think a bunch of tools DO analyze git logs to do
 the work; commit-queue, webkitbot, etc...


e.g. MarkBugFixed._determine_bug_id_and_svn_revision
uses tool.scm().svn_commit_log to figure out the bug number.  In fact, the
code assumes that the commit log uses the same format as the change log and
uses changelog.py's parse_bug_id_from_changelog

In fact, making change log  commit log use a different format is much more
challenging than changing the format of change log  commit log.  It
requires A LOT of refactoring and bug fixes in webkitpy.  I don't even know
much work is required for webkitperl and other tools.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Carlos Garcia Campos
El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
 On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org
 wrote:
 On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
 carlo...@webkit.org wrote:
 
 El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa
 escribió:
  Hi,
 
 [...]
 
  Separately, I'd like to know whether people liked
 the new format and
  it's worth my time making webkitpy adopt the new
 format.
 
 
 I prefer the old format.
 
 
  I personally didn't like the old format because it
 made the first line
  of each change log too long.  I'm also not a big fun
 of wrapping URLs
  in angle brackets.  It's also unclear to me what
 should happen when
  there are multiple Bugzilla URLs to list.
 
 
  But I hear the new format made git log --oneline
 much more readable so
  I can be convinced although I don't intend to use
 git for WebKit
  development in the foreseeable future myself.
 
 
 Well, git log is not actually affected by the
 ChangeLog format, but by
 the commit message. I mean, we generate the commit
 message from the
 ChangeLog, so we can keep the old format in the
 ChangeLog and update the
 script to generate the commit message to make it
 better for oneline git
 log format. webkitpy parses the ChangeLog not the
 commit message, so
 everything should work.
 
 
 If I'm not mistaken, I think a bunch of tools DO analyze git
 logs to do the work; commit-queue, webkitbot, etc...
 
 
 e.g. MarkBugFixed._determine_bug_id_and_svn_revision
 uses tool.scm().svn_commit_log to figure out the bug number.  In fact,
 the code assumes that the commit log uses the same format as the
 change log and uses changelog.py's parse_bug_id_from_changelog
 
 
 In fact, making change log  commit log use a different format is much
 more challenging than changing the format of change log  commit log.
  It requires A LOT of refactoring and bug fixes in webkitpy.  I don't
 even know much work is required for webkitperl and other tools.

I see, I thought ChangeLog parser was used everywhere. So, I guess the
solution would be to find a format most people like and adapt all
scripts to it. I personally think it's not worth it, though. The oneline
git log format is ok with the old commit message format IMO. If the only
problem is that the bug number is not in the first line we can probably
add it without adding the URL in angle brackets, something like:

Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
https://bugs.webkit.org/show_bug.cgi?id=119872

 
 - R. Niwa
 
 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Filip Pizlo
+1 for the old format.

-F


On Aug 21, 2013, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:

 El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
 On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org
 wrote:
On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
carlo...@webkit.org wrote:
 
El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa
escribió:
 Hi,
 
[...]
 
 Separately, I'd like to know whether people liked
the new format and
 it's worth my time making webkitpy adopt the new
format.
 
 
I prefer the old format.
 
 
 I personally didn't like the old format because it
made the first line
 of each change log too long.  I'm also not a big fun
of wrapping URLs
 in angle brackets.  It's also unclear to me what
should happen when
 there are multiple Bugzilla URLs to list.
 
 
 But I hear the new format made git log --oneline
much more readable so
 I can be convinced although I don't intend to use
git for WebKit
 development in the foreseeable future myself.
 
 
Well, git log is not actually affected by the
ChangeLog format, but by
the commit message. I mean, we generate the commit
message from the
ChangeLog, so we can keep the old format in the
ChangeLog and update the
script to generate the commit message to make it
better for oneline git
log format. webkitpy parses the ChangeLog not the
commit message, so
everything should work.
 
 
If I'm not mistaken, I think a bunch of tools DO analyze git
logs to do the work; commit-queue, webkitbot, etc...
 
 
 e.g. MarkBugFixed._determine_bug_id_and_svn_revision
 uses tool.scm().svn_commit_log to figure out the bug number.  In fact,
 the code assumes that the commit log uses the same format as the
 change log and uses changelog.py's parse_bug_id_from_changelog
 
 
 In fact, making change log  commit log use a different format is much
 more challenging than changing the format of change log  commit log.
 It requires A LOT of refactoring and bug fixes in webkitpy.  I don't
 even know much work is required for webkitperl and other tools.
 
 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872
 
 
 - R. Niwa
 
 
 
 -- 
 Carlos Garcia Campos
 http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Ryosuke Niwa
On Wed, Aug 21, 2013 at 11:11 PM, Carlos Garcia Campos
carlo...@webkit.orgwrote:

 El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
  On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org
  wrote:
  On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
  carlo...@webkit.org wrote:
 
  El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa
  escribió:
   Hi,
 
  [...]
  
   Separately, I'd like to know whether people liked
  the new format and
   it's worth my time making webkitpy adopt the new
  format.
 
 
  I prefer the old format.
 
  
   I personally didn't like the old format because it
  made the first line
   of each change log too long.  I'm also not a big fun
  of wrapping URLs
   in angle brackets.  It's also unclear to me what
  should happen when
   there are multiple Bugzilla URLs to list.
  
  
   But I hear the new format made git log --oneline
  much more readable so
   I can be convinced although I don't intend to use
  git for WebKit
   development in the foreseeable future myself.
 
 
  Well, git log is not actually affected by the
  ChangeLog format, but by
  the commit message. I mean, we generate the commit
  message from the
  ChangeLog, so we can keep the old format in the
  ChangeLog and update the
  script to generate the commit message to make it
  better for oneline git
  log format. webkitpy parses the ChangeLog not the
  commit message, so
  everything should work.
 
 
  If I'm not mistaken, I think a bunch of tools DO analyze git
  logs to do the work; commit-queue, webkitbot, etc...
 
 
  e.g. MarkBugFixed._determine_bug_id_and_svn_revision
  uses tool.scm().svn_commit_log to figure out the bug number.  In fact,
  the code assumes that the commit log uses the same format as the
  change log and uses changelog.py's parse_bug_id_from_changelog
 
 
  In fact, making change log  commit log use a different format is much
  more challenging than changing the format of change log  commit log.
   It requires A LOT of refactoring and bug fixes in webkitpy.  I don't
  even know much work is required for webkitperl and other tools.

 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:

 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872


I like this idea. It matches what Bugzilla shows.

I'd like to hear the opinions of people who use git log —online though.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Mark Rowe

On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:

 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872

What benefit does duplicating the bug number in the first line provide? It’s 
just yet another thing to have to add when writing the ChangeLog entry.

- Mark

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


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Carlos Garcia Campos
El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
 On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
 
  I see, I thought ChangeLog parser was used everywhere. So, I guess the
  solution would be to find a format most people like and adapt all
  scripts to it. I personally think it's not worth it, though. The oneline
  git log format is ok with the old commit message format IMO. If the only
  problem is that the bug number is not in the first line we can probably
  add it without adding the URL in angle brackets, something like:
  
  Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
  https://bugs.webkit.org/show_bug.cgi?id=119872
 
 What benefit does duplicating the bug number in the first line provide? It’s 
 just yet another thing to have to add when writing the ChangeLog entry.

The benefit is that you see the bug number when using git log oneline
format, I'm guessing that seeing the bug number in the first line was
the motivation of the new ChangeLog format.

 - Mark
 
 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Mark Rowe

On 2013-08-22, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:

 El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
 On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
 
 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872
 
 What benefit does duplicating the bug number in the first line provide? It’s 
 just yet another thing to have to add when writing the ChangeLog entry.
 
 The benefit is that you see the bug number when using git log oneline
 format, I'm guessing that seeing the bug number in the first line was
 the motivation of the new ChangeLog format.

I’m ok with moving it in to the first line, but I’m against duplicating it.

- Mark

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


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Maciej Stachowiak

From the new format, I like the shorter bug URL and the angle brackets, but I 
don't care much either way about putting the bug URL and title on the same 
line.

One downside though is that, if you're composing a ChangeLog more manually, 
it's more awkward to construct the new-style URL since you can't just copy from 
the URL field.

 - Maciej

On Aug 21, 2013, at 2:25 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Aug 21, 2013 at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Hi,
 
 I have noticed that the change log format has recently been changed.  
 Unfortunately, this didn't work well with all webkitpy tools we have, and has 
 been rolled out in http://trac.webkit.org/changeset/154406.
 
 I kindly ask you to manually edit your patch to use the old format before 
 landing your patch for now.
 
 To clarify, the old multi-line format looks like:
 
 2013-08-13  Ryosuke Niwa  rn...@webkit.org
 
 REGRESSION(r150187): Safari fails to render allrecipe.com comment 
 popups
 https://bugs.webkit.org/show_bug.cgi?id=119780
 
 Reviewed by Benjamin Poulain.
 
 while new single-line format looked like:
 
 2013-08-18  Ryosuke Niwa  rn...@webkit.org
 
 https://webkit.org/b/119917 Pasting multiple lines into a textarea 
 can introduce extra new lines
 
 Reviewed by Darin Adler.
 
 Separately, I'd like to know whether people liked the new format and it's 
 worth my time making webkitpy adopt the new format.
 
 I personally didn't like the new single-line format because it made the first 
 line of each change log too long.  I'm also not a big fun of wrapping URLs in 
 angle brackets.  It's also unclear to me what should happen when there are 
 multiple Bugzilla URLs to list.
 
 But I hear the new format made git log --oneline much more readable so I can 
 be convinced although I don't intend to use git for WebKit development in the 
 foreseeable future myself.
 
 - R. Niwa
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Maciej Stachowiak

On Aug 22, 2013, at 12:48 AM, Mark Rowe mr...@apple.com wrote:

 
 On 2013-08-22, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:
 
 El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
 On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org 
 wrote:
 
 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872
 
 What benefit does duplicating the bug number in the first line provide? 
 It’s just yet another thing to have to add when writing the ChangeLog entry.
 
 The benefit is that you see the bug number when using git log oneline
 format, I'm guessing that seeing the bug number in the first line was
 the motivation of the new ChangeLog format.
 
 I’m ok with moving it in to the first line, but I’m against duplicating it.

I agree with this. It seems janky to include it twice.

 - Maciej

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


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Joseph Pecoraro

On Aug 22, 2013, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:

 El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
 On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
 
 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872
 
 What benefit does duplicating the bug number in the first line provide? It’s 
 just yet another thing to have to add when writing the ChangeLog entry.
 
 The benefit is that you see the bug number when using git log oneline
 format, I'm guessing that seeing the bug number in the first line was
 the motivation of the new ChangeLog format.


I prefer the new format. However, the new format doesn't really gain us much, 
so it sounds like it is not worth the effort to change.

As for duplicating the bug number, I don't think that matters. `git log 
--oneline` shows a short SHA the title line which is everything in the commit 
message until the first empty line. So duplicating the bug number in the first 
line doesn't really help, since both of these lines already show up.

Old format:

shell git log --oneline `git svn find-rev r153963` -10
503293b Move additionalIdentifiers into DFGCommonData as only the optimising 
JITs use them https://bugs.webkit.org/show_bug.cgi?id=119705
2dbc921 Stop making unnecessary copy of CodeBlock Identifier Vector 
https://bugs.webkit.org/show_bug.cgi?id=119702
c0c68df [cairo] memory corruption with putImageData and accelerated canvas. 
https://bugs.webkit.org/show_bug.cgi?id=118621
0502819 Layout Test fast/overflow/scrollbar-click-retains-focus.html is failing 
on Apple Mac WK1 and GTK. https://bugs.webkit.org/show_bug.cgi?id=104104
c19a87b Use const AtomicStringImpl* in DocumentOrderedMap 
https://bugs.webkit.org/show_bug.cgi?id=119700
02c59d8 The LayoutMilestones didLayout callback should only fire for the main 
frame https://bugs.webkit.org/show_bug.cgi?id=119457
2cb3317 Remove didNewFirstVisuallyNonEmptyLayout from WebKit2 
https://bugs.webkit.org/show_bug.cgi?id=119658
6cb5165 Define DOM_KEY_LOCATION_* constants on KeyboardEvent 
https://bugs.webkit.org/show_bug.cgi?id=119341
597845d Remove glu's libtest rule from checker.py 
https://bugs.webkit.org/show_bug.cgi?id=119674
35852cd Multiple CSP tests complain about undefined strings in 
echo-object-data.pl and echo-script-src.pl 
https://bugs.webkit.org/show_bug.cgi?id=119692

New format:

shell git log --oneline `git svn find-rev r154274` -10
c3bd590 https://webkit.org/b/119882 Speed up moving cursor/selection up or 
down past non-rendered elements.
6c326ac https://webkit.org/b/119933 [Qt] Fix 
tst_QObjectBridge::connectAndDisconnect() fail
381c093 https://webkit.org/b/12 Chrome::client() should return a 
reference.
f183c4b https://webkit.org/b/120004 Rename StyleElement to 
InlineStyleSheetOwner and stop inheriting from it
0d74bc3 [Qt] QtWebKit (using the Arora browser) displays the border radii 
(radius) of a button very ugly https://bugs.webkit.org/show_bug.cgi?id=28113
e5a4a31 https://webkit.org/b/119998 [Qt] Build fix (broken since r154257).
d3ac166 https://webkit.org/b/120001 Clean up StyleElement
5c403bd https://webkit.org/b/119990 Add toSVGStopElement(Node* node) to 
clean-up a static_castSVGStopElement*
508cc36 https://webkit.org/b/119996 Introduce toSVGAnimateElement(), and use 
it
db5024b https://webkit.org/b/119997 Page::progress() should return a 
reference.

- Joe___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev