It also strikes me that we'd have have trouble filtering out reverts using
the RELEASE_NOTE tag. Since the original change with the RELEASE_NOTE tag
and the reverted change would be in different revisions I'm not sure a
simple grep would suffice.
Kind Regards,
Anthony Laforge
Technical Program
-100 million to changelogs.
On Wed, Jul 22, 2009 at 8:28 AM, Anthony LaForgelafo...@google.com wrote:
It also strikes me that we'd have have trouble filtering out reverts using
the RELEASE_NOTE tag. Since the original change with the RELEASE_NOTE tag
and the reverted change would be in
+1 No manual changelogs.
-Ben
On Tue, Jul 21, 2009 at 9:56 PM, Adam Barthaba...@chromium.org wrote:
WebKit uses ChangeLogs for every commit and they are a royal pain,
requiring an entire suite of scripts to handle generation, merges, and
conflicts. I hope we can find a better solution.
You can still have a single file/URL with this info for convenience. Just
auto-generate it from the svn-logs. You lose the ability to edit it and
make it look nice, but that could be done manually as a separate file if
you'd like.
Erik
On Tue, Jul 21, 2009 at 11:08 PM, Anthony LaForge
The point about reverts is confusing RELEASE_NOTE is a good one, but I
don't think it outweighs the pain of maintaining ChangeLog.
On Wed, Jul 22, 2009 at 8:41 AM, Erik Kayerik...@chromium.org wrote:
You can still have a single file/URL with this info for convenience. Just
auto-generate it
If reverting RELEASE_NOTE really becomes a big problem, someone could
write a wrapper script to manage that. That seems more sensible than
adding a manually-maintained file.
I'm not really sure if the right solution would be to drop
RELEASE_NOTE for items which are reverted. If they are
Ok, I know when to stop pushing, that's reasonable and appreciated feedback.
So shifting gears, it seems like everyone would be comfortable with using
RELEASE_NOTES tag in SVN comments. Any thoughts from the group on best
practices for using that the tag gets used effectively?
Kind Regards,
On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote:
On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com
wrote:
Ok, I know when to stop pushing, that's reasonable and appreciated
feedback.
So shifting gears, it seems like everyone would be comfortable
On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote:
...
Actually, I've never been too sure about reverting in WebKit: does one
revert the ChangeLog file too or add another ChangeLog entry at the
top describing the revert?
Unless my memory is faulty, according to the
On Wed, Jul 22, 2009 at 10:13 AM, Darin Fisherda...@chromium.org wrote:
On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote:
Actually, I've never been too sure about reverting in WebKit: does one
revert the ChangeLog file too or add another ChangeLog entry at the
top
(Warning: TPM perspective) The main problem with the current system is that
it's a very time consuming process to parse through ~1000 revisions each
week. Even with filter tools which parse the SVN logs and look for
revisions with closed bugs, specific keywords in the logs, specific files,
On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForge lafo...@google.comwrote:
Even with filter tools which parse the SVN logs and look for revisions with
closed bugs, specific keywords in the logs, specific files, auto-discarding
reverts, etc... that still brings us down to about 150 entries that
The stuff I'm implementing is important to _me_, but is it important
enough to be in the release notes?
Maybe we should have a tag for the issue-tracker which indicates that
the issue is release-note-worthy, and we could use action on those
bugs to help figure out which items are worthy of being
BTW: if people aren't annotating their CL's with bugs, they SURELY
won't annotate them with release notes or update the change log. Just
aiming for the path of least resistance, here.
-scott
On Wed, Jul 22, 2009 at 11:46 AM, Scott Hesssh...@chromium.org wrote:
The stuff I'm implementing is
If you don't want to see this thread anymore you can use the 'm' shortcut to
mute it.
If you don't have a BUG in your commit comment then we probably won't even
see your CL and it won't make the release notes.
It would be enough, IMHO, to have the first line of your commit comment
describe the
-1000 to manual changelog updates
+1 to a changelog populated by a commit trigger. Having a
local/offline copy of the change history can be useful, in the absence
of git.
-100 to reverts deleting stuff from changelogs. changelogs should be
(except in exceptional circumstances) append only, just
It sounds like better CL descriptions will make most of the problems go
away. Ojan started a new thread about this.
If people don't put BUG='s in their CL descriptions or won't use the
RELEASE_NOTES annotation, there's no hope for them using a ChangeLog.
Is this dead horse sufficiently beaten?
I like Scott's idea, if you think your patch is ChangeLog worthy, add some
sort of release-note-worthy key on the bottom of the commit description.
And as Peter stated, make sure the first line of the commit message is very
descriptive that explains what this release note worthy message is really
On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForge lafo...@google.com wrote:
In order to make it easier for the community to see the changes are going
on inside Chromium I'd like to propose that we add one or more ChangeLog
files into our code base. The proposed usage would go something like
On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForgelafo...@google.com wrote:
In order to make it easier for the community to see the changes are going on
inside Chromium I'd like to propose that we add one or more ChangeLog files
into our code base. The proposed usage would go something like
20 matches
Mail list logo
