(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,
auto-discarding reverts, etc... that still brings us down to about 150
entries that require manual review. Of those, a good portion are
not immediately clear from either the bug title or the SVN summary as to
exactly what the fix was for, which requires extra detective work. Once
that's done we end up re-writing/ clarifying the text. Even with all that
effort I'm not 100% satisfied that we're coming up with what I'd call good
results (we hit most things, but it's easy to miss lots of important stuff).
Given the labor intensiveness and the so so yield, it seems like this
process is an excellent candidate for applying some distributed labor and
automation. I understand the resistance to ChangeLogs, but it doesn't seem
unreasonable to ask committers, who have the best sense of the nature of
their work, to take an extra minute to put a single line descriptive comment
along side their SVN commit (and for reviewers to check it).
Kind Regards,
Anthony Laforge
Technical Program Manager
Mountain View, CA
External Phone: 1-650-214-4055
On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting <pkast...@google.com> wrote:
> 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 LaForge<lafo...@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 with
>> using
>> > RELEASE_NOTES tag in SVN comments. Any thoughts from the group on best
>> > practices for using that the tag gets used effectively?
>>
>
> Who said everyone was comfortable? I'm probably not going to bother
> writing RELEASE_NOTES pretty much ever. (In exchange, I frequently edit our
> release notes to be more complete or accurate.)
>
> If the goal is pointing people at something that lists all changes, we can
> do it with a script. If the goal is making the release notes for releases
> better, a ChangeLog wouldn't have helped you anyway. I'm not sure there is
> much advantage in modifications to the current system -- even if
> RELEASE_NOTES get written sometimes, you're still going to need to parse all
> the rest of the changes and decide what to say.
>
> * When reverting, the log is reverted as well:
>>
>> 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 Apple folks who have guided me
> through reverts (in particular, bdash), you add a new entry at top saying
> you're reverting; you never remove the old CL entry.
>
> But, the commit message should match the change message on the code
>> review, so our reviewers can already critique it. So, this would
>> appear to be a review issue rather than a technological issue.
>
>
> Yes, and if reviewers aren't complaining about poor descriptions here, they
> should be.
>
> PK
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
