[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 Manager Mountain View, CA On Tue, Jul 21, 2009 at 11:08 PM, Anthony LaForge lafo...@google.comwrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: 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 this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
-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 different revisions I'm not sure a simple grep would suffice. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 11:08 PM, Anthony LaForge lafo...@google.com wrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: 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 this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
+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. Adam 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 this: When a developer completes a visible or notable change, they'd add an entry to the ChangeLog along with their commit. The entry would have the date, author, a plain English description (suitable for release notes) of the change, along with a reference to any related bugs. Example: 2009-07-21 [lafo...@chromium.org]: Creating a patch to make change tracking easier (Bugs:12345,67890) Immediate Benefits: Assuming that changes were checked in with the code they were mapped to, ChangeLogs would stay up to date even through reverts and branch merges. It would be very easy, given a range of revisions to see what precisely changed in Chromium. Overall, I think this would make it much simpler to view the team's progress and help us improve our overall level of transparency. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 lafo...@google.comwrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: 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 this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 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 lafo...@google.com wrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: 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 this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 reverted quickly, say because they broke the build, sure, but at some point the original RELEASE_NOTE and the revert RELEASE_NOTE become distinct bits of information. -scott On Wed, Jul 22, 2009 at 9:31 AM, Aaron Boodmana...@chromium.org wrote: 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 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 lafo...@google.com wrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: 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 this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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, Anthony Laforge Technical Program Manager Mountain View, CA External Phone: 1-650-214-4055 On Wed, Jul 22, 2009 at 9:40 AM, Peter Kasting pkast...@google.com wrote: Also chipping in an over my dead body to ChangeLogs. If you want to point people at a file containing this, it is supremely easy to have a script dump the commits to a file that's accessible from the web. This produces the result you want with no developer hassle. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 with using RELEASE_NOTES tag in SVN comments. Any thoughts from the group on best practices for using that the tag gets used effectively? I think everyone who has dealt with WebKit hates ChangeLogs as much as hate is being too kind. I do, but let's consider what advantages they would bring so that we can try and have the benefits without the costs: * 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? I revert the ChangeLog addition so that after the revert is complete there is no trace in the ChangeLog of the change. I do the latter, but if we chose to do the former then this would solve an issue where a script wouldn't know, from the commit logs, about reverted changes. Suggestion: REVERT=12345 in the change log when reverting. Scripts can then process this. * By having the ChangeLog in the review, reviewers can critique it. Many of our commit messages are little brief. Some are far too brief. 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. I think we need to remember to review the CL description. It is easy to overlook when reviewing an issue. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 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. Oh, good to know! -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 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. bugzilla-tool will soon do this all for you: https://bugs.webkit.org/show_bug.cgi?id=26715 -eric --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
(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 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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 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. I'm not terribly sympathetic here. My home machine lacks all those tools and I was able to write up a set of detailed release notes (for a release that had been given near none) in my spare time in about two hours one evening. 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). So? Or to be less brief, what's the impact of the release notes missing some changes? No one is going to die. The audience here is curious enthusiasts who like to read What's New items. Our past release notes have missed tons of big things. 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). Committers already should be writing a description of their work and reviewers should be checking it. If it's not clear enough, I don't think the solution is to ask for two descriptions. I think we should instead ask people to take more time to write a clearer description that hits the high points in the first sentence. (Notorious bad messages: This fixes bug 12345. Fix some problems. .) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 LaForgelafo...@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 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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 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 LaForgelafo...@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 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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 change in a way that makes it clear that it should be highlighted in the release notes. A tag would be even better, but I understand all that extra typing can be tiresome. Anthony was not looking for a CHANGE_LOG like WebKit which included each CL. We already provide a link to all the CL commentshttp://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcrange=20903:21176mode=htmlfor a release. He was looking for an entry to a file each time you have something release note worthy. My experience is that we have about 5 items that rise to this level with each release. If you don't want to do any of these things then you should subscribe to cr-rel-notify so you can see the proposed blog entry before it goes out. Then you can let us know when we have missed something interesting. Jon On Wed, Jul 22, 2009 at 11:47 AM, Scott Hess sh...@chromium.org wrote: 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 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 LaForgelafo...@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 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 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
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
-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 like version control. Seems to me that any substantive change or feature addition should be tracked by a bug, and that bug should have a 'feature' or 'release_note' flag associated with it. Then writing a script to pull all the relevant notes would be pretty easy. -- Dirk 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 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. Oh, good to know! -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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? :-) J On Wed, Jul 22, 2009 at 12:32 PM, Jon j...@chromium.org wrote: 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 change in a way that makes it clear that it should be highlighted in the release notes. A tag would be even better, but I understand all that extra typing can be tiresome. Anthony was not looking for a CHANGE_LOG like WebKit which included each CL. We already provide a link to all the CL commentshttp://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcrange=20903:21176mode=htmlfor a release. He was looking for an entry to a file each time you have something release note worthy. My experience is that we have about 5 items that rise to this level with each release. If you don't want to do any of these things then you should subscribe to cr-rel-notify so you can see the proposed blog entry before it goes out. Then you can let us know when we have missed something interesting. Jon On Wed, Jul 22, 2009 at 11:47 AM, Scott Hess sh...@chromium.org wrote: 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 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 LaForgelafo...@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 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 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,
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 about. I believe those two approaches will make it easier for the developers and the managers to produce release notes. A simple script (python since you all like python) could read the log since the last release and correctly parse out release-note-worthy Maybe modify bugdroid to parse out release-note-worthy and send an email to the people responsible everytime that is there. -- Mohamed Mansour On Wed, Jul 22, 2009 at 3:48 PM, Jeremy Orlow jor...@chromium.org wrote: 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? :-) J On Wed, Jul 22, 2009 at 12:32 PM, Jon j...@chromium.org wrote: 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 change in a way that makes it clear that it should be highlighted in the release notes. A tag would be even better, but I understand all that extra typing can be tiresome. Anthony was not looking for a CHANGE_LOG like WebKit which included each CL. We already provide a link to all the CL commentshttp://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcrange=20903:21176mode=htmlfor a release. He was looking for an entry to a file each time you have something release note worthy. My experience is that we have about 5 items that rise to this level with each release. If you don't want to do any of these things then you should subscribe to cr-rel-notify so you can see the proposed blog entry before it goes out. Then you can let us know when we have missed something interesting. Jon On Wed, Jul 22, 2009 at 11:47 AM, Scott Hess sh...@chromium.org wrote: 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 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 LaForgelafo...@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 LaForgelafo...@google.com wrote: Ok, I know when to stop pushing, that's reasonable and
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 this: - When a developer completes a visible or notable change, they'd add an entry to the ChangeLog along with their commit. - The entry would have the date, author, a plain English description (suitable for release notes) of the change, along with a reference to any related bugs. - Example: 2009-07-21 [lafo...@chromium.org]: Creating a patch to make change tracking easier (Bugs:12345,67890) *Immediate Benefits:* - Assuming that changes were checked in with the code they were mapped to, ChangeLogs would stay up to date even through reverts and branch merges. - It would be very easy, given a range of revisions to see what precisely changed in Chromium. Overall, I think this would make it much simpler to view the team's progress and help us improve our overall level of transparency. I am very against adding ChangeLogs unless absolutely necessary. They're a major pain in WebKit development...enough so that there have been pushes to get rid of them there. It's nice that you're only asking for major changes to be added to the ChangeLog, but I still think it's going to add a lot of overhead. ChangeLogs mean that you can only have one (change-log-worthy) change per client at a time. They also mean that every time you sync your client, you're going to have to resolve conflicts. WebKit has a script to do this for you, but it's still a pain. I don't understand why the svn commit logs aren't enough for our purposes here. Especially if we use the RELEASE_NOTE annotation Aaron suggested. Does this information not get carried forward with branches? Could we create a script that automatically generates ChangeLogs based on the svn commit logs if not? J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
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 this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
