On Sep 1, 2009, at 12:59 PM, Adam Roben wrote:
2009-09-01 Adam Roben aro...@apple.com
Reviewed by NOBODY (OOPS!)
Need a short description of this patch (OOPS!)
Need a bug title and URL (OOPS!)
What do others think?
With the detriment of adding Y.A.O. (yet another
On Thu, 2009-07-09 at 14:32 -0400, tonikitoo (Antonio Gomes) wrote:
I grew up listing and seeing people not writing their emails *as it*
and publishing on the internet
so would replacing m...@apple.com by mjs at apple dot com be a
good practice ?
I always failed to see much wisdom in
On Fri, 2009-07-10 at 18:18 -0700, John Abd-El-Malek wrote:
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
I don't want to open the can of worms that is git vs other source control
systems. However given that the instructions for developing WebKit are for
svn and there already exists svn-apply/unapply scripts, I think there are
enough WebKit devs using svn that warrant improving this process flow.
On
On Wednesday 15 July 2009 03:59:53 pm John Abd-El-Malek wrote:
I don't want to open the can of worms that is git vs other source control
systems. However given that the instructions for developing WebKit are for
svn and there already exists svn-apply/unapply scripts, I think there are
enough
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
-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
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)?
2009-07-08 Maciej Stachowiak m...@apple.com
Make
On Thu, Jul 9, 2009 at 1:32 AM, Maciej Stachowiakm...@apple.com wrote:
Is that a format everyone can live with for ChangeLogs and commit messages?
If so, I'll post a patch to update prepare-ChangeLog accordingly.
LGTM
___
webkit-dev mailing list
I discussed with Mark Rowe on IRC a bit and it seems like it would be
nice if the bug URL could be short enough to just go on one line with
the summary. Which turns out to be totally doable. Thus the latest
format proposal (the /b/ URL is a redirect):
2009-07-08 Maciej Stachowiak
Message
From: Maciej Stachowiak m...@apple.com
To: Maciej Stachowiak m...@apple.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Thursday, July 9, 2009 1:47:16 AM
Subject: Re: [webkit-dev] Changes to prepare-ChangeLog
I discussed with Mark Rowe on IRC a bit and it seems like
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
On Jul 9, 2009, at 1:47 AM, Maciej Stachowiak wrote:
(the /b/ URL is a redirect):
I'm like most everything suggested in this thread.
But I'm a little sad that these new shorter URLs are redirects. I
really like to copy URLs out of the address field, so I’d want the
legacy show_bug.cgi
On Jul 9, 2009, at 8:52 AM, Darin Adler wrote:
On Jul 9, 2009, at 1:47 AM, Maciej Stachowiak wrote:
(the /b/ URL is a redirect):
I'm like most everything suggested in this thread.
But I'm a little sad that these new shorter URLs are redirects. I
really like to copy URLs out of the
I grew up listing and seeing people not writing their emails *as it*
and publishing on the internet
so would replacing m...@apple.com by mjs at apple dot com be a
good practice ?
it reduces the spam count in your inbox for sure.
On Thu, Jul 9, 2009 at 2:11 PM, Maciej Stachowiakm...@apple.com
On Thursday, July 9, 2009 11:06:58 AM, Maciej Stachowiak wrote:
On Jul 9, 2009, at 4:33 AM, David Kilzer wrote:
* What does the format look like for bugs with multiple URL
links, e.g., to rdar://problem/NNN or to
http://crbug.com/N? (The title should not have to be
repeated--you
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)?
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
I didn't solve every possible problem with prepare-ChangeLog, but I
tried to make it a bit less shouty.
If you don't provide the --bug argument, it includes text like this:
-
2009-07-08 Maciej Stachowiak m...@apple.com
Reviewed by NOBODY (OOPS!).
Need a short
I had intended to summarize this long thread which I started. But
I've since realized that we're mostly bikeshedding here, so there
isn't much actionable takeaway. :( Thank you to all of you for your
thoughtful responses!
I'm not at all attached to the current YELLING CHANGELOG TEMPLATE. :)
But
Oh, I did really like the idea of a prepare-ChangeLog wizard which
someone suggested. Where it might ask you some of the relevant
questions instead of filling in boilerplate.
I continue to find it frustrating that I have to r- patches with bad
ChangeLogs. :) I don't think that's so much
02.07.2009, в 18:05, Adam Roben написал(а):
- I prefer having Bug N: before the actual bug description
so I don't have to parse the URL myself for the bug number. It
also acts as a visual marker when I read the ChangeLog entry.
...
Here's an example entry that follows the format
Since this seems to have become the new bikeshed, I'll chime in with my
color preference:
Reviewed by John Smith (jsm...@webkit.org)
https://bugs.webkit.org/show_bug.cgi?id=123456
Fix WebKit being not awesome enough. Make five files more awesome.
FWIW, I agree with those who desire
On Fri, Jul 3, 2009 at 10:24 AM, Peter Kasting pkast...@google.com wrote:
Since this seems to have become the new bikeshed, I'll chime in with my
color preference:
Reviewed by John Smith (jsm...@webkit.org)
https://bugs.webkit.org/show_bug.cgi?id=123456
Fix WebKit being not awesome
On Jul 2, 2009, at 12:40 AM, Eric Seidel wrote:
Agreed. Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)
Darin is certainly more conscientious about this than most people, but
a quick glance at WebCore's ChangeLog shows that many
On Jul 3, 2009, at 10:44 AM, Jeremy Orlow wrote:
On Fri, Jul 3, 2009 at 10:24 AM, Peter Kasting pkast...@google.com
wrote:
Since this seems to have become the new bikeshed, I'll chime in with
my color preference:
Reviewed by John Smith (jsm...@webkit.org)
On Friday, July 3, 2009 3:20:58 AM, Alexey Proskuryakov wrote:
02.07.2009, в 18:05, Adam Roben написал(а):
Here's an example entry that follows the format that I (and
I think Dave) like:
+2009-04-20 Adam Roben aro...@apple.com
+
+Change MemoryStream::createInstance to
On Friday, July 3, 2009 2:19:51 PM, Maciej Stachowiak wrote:
What I do (and I think many of us do) is use a script that
automatically fills in the commit message from the ChangeLog.
The script is WebKitTools/Scripts/commit-log-editor. Setting one of these
environment variables (depending on
02.07.2009, в 9:44, Eric Seidel написал(а):
DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
http://webkit.org/coding/contributing.html FOR MORE INFORMATION
Tests: fast/foo.html
* foo.cpp: Added.
|n most cases, detailed description of changes would
On Jul 1, 2009, at 10:47 PM, Dan Bernstein wrote:
On Jul 1, 2009, at 10:44 PM, Eric Seidel wrote:
prepare-ChangeLog should have a --bug= argument and use it for
url autofill
https://bugs.webkit.org/show_bug.cgi?id=26383
I would much prefer if the bug URL came first. I believe
Agreed. Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)
But you're right, that the message could be made more clear. Maybe
something like:
CHANGE DESCRIPTION GOES HERE. (OOPS!) SEE:
http://webkit.org/coding/contributing.html FOR MORE
On Thu, Jul 02, 2009 at 01:01:09AM -0700, Adam Barth aba...@webkit.org wrote:
On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommeymh+web...@glandium.org wrote:
I've always wondered, in the days of atomic commits and advanced SCM, why
fill changelogs at all ? Except for CVS, RCS or SCCS, any SCM
On Wednesday, July 1, 2009 10:44:16 PM, Eric Seidel e...@webkit.org wrote:
Results in:
2009-07-01 Eric Seidel e...@webkit.org
Reviewed by NOBODY (OOPS!).
prepare-ChangeLog should have a --bug= argument and use it for
url autofill
On Jul 2, 2009, at 9:14 AM, David Kilzer wrote:
On Wednesday, July 1, 2009 10:44:16 PM, Eric Seidel
e...@webkit.org wrote:
Results in:
2009-07-01 Eric Seidel e...@webkit.org
Reviewed by NOBODY (OOPS!).
prepare-ChangeLog should have a --bug= argument and use it
for
On Jul 2, 2009, at 4:07 AM, Mike Hommey wrote:
On Thu, Jul 02, 2009 at 01:01:09AM -0700, Adam Barth aba...@webkit.org
wrote:
On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommeymh
+web...@glandium.org wrote:
I've always wondered, in the days of atomic commits and advanced
SCM, why
fill changelogs
Maciej Stachowiak wrote:
With SVN at least, it's a lot faster and easier to do a text search on
the ChangeLog than to retrieve and search the commit log history.
Searching the actual commit logs is very slow online and doesn't work at
all offline. The ChangeLog also ends up in static tarball
On Jul 2, 2009, at 12:40 AM, Eric Seidel wrote:
Agreed. Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)
But you're right, that the message could be made more clear. Maybe
something like:
CHANGE DESCRIPTION GOES HERE. (OOPS!) SEE:
I also agree and that is the style I use.
On Jul 2, 2009, at 7:05 AM, Adam Roben wrote:
- I generally move the Reviewed by line after the bug number/
description/URL. When you're reading a ChangeLog entry/commit
message (especially an older one), it's generally much more
interesting which
On Jul 2, 2009, at 2:50 PM, Timothy Hatcher wrote:
Having it all on the dateline is not the best for git users either.
We usually remove that line, since git shows the first line of the
commit log in many places.
In retrospect, committing to SVN also usually removes this line so I
While clearly a personal preference, I don't like the default
prepare-changelog default text and would much rather we revert to the old
one. I don't think the new text adds anything and will likely be ignored by
most. Can we leave the --bug= option and revert to the old template?
-Sam
On Wed,
On Jul 2, 2009, at 4:52 PM, Sam Weinig wrote:
While clearly a personal preference, I don't like the default
prepare-changelog default text and would much rather we revert to
the old one. I don't think the new text adds anything and will
likely be ignored by most. Can we leave the --bug=
Background: Reviewers spend too much time correcting errors which
should be caught by tools. This is frustrating both to contributers
and reviewers. One such class of errors are missing or incorrect
information in ChangeLogs. I'm trying to fix that.
As part of:
On Jul 1, 2009, at 10:44 PM, Eric Seidel wrote:
prepare-ChangeLog should have a --bug= argument and use it for
url autofill
https://bugs.webkit.org/show_bug.cgi?id=26383
I would much prefer if the bug URL came first. I believe that this is
the prevailing style.
Thanks,
—Dan
43 matches
Mail list logo
