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 in the release
notes? Then if someone complains that their change didn't make the
release notes, we can tell them how to arrange for that in the future.
From there, regular bug triage activities may suffice to work it down
to a reasonable volume.
-scott
On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForge<lafo...@google.com> wrote:
> (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
-~----------~----~----~----~------~----~------~--~---
