I fully support this. We have been using similar procedure in Google Desktop for a while (and probably others within Google). The benefit is easier traceability and long term time saving. We have extended this in some ways:A) Made the BUG field required - you need to explicitly say BUG=0 if there is no bug. This prevents people from forgetting to add the field (common) or skipping it because they are to lazy to lookup the bug-id or or report a bug (not too uncommon). B) Made the BUG field travel across merges. That way the original bug is automatically updated for each branch and it's easy to see if a particular version should have something fixed. C) Used bugs to track releases. Since bugs are pretty good at tracking lifetime you can in one place check status of testing and see what issues (tracked through blocking bugs) have come up. Builds are then marked as will-not-fix or fixed depending on if they are released or not.
I think we should consider A) immediately for Chrome and the other two in the near future. Sverrir PS Will you update the external documentation to reflect this Mark? On Thu, Apr 23, 2009 at 2:40 AM, Mark Larson (Google) <[email protected]>wrote: > All changelists should have > > TEST= > BUG= > > if at all feasible. > > Why? > > TEST= will ensure that testers get the information they need to cover your > change. What needs to be tested is not always obvious from the CL > description. Sometimes a change in base/ can impact the installer or > downloads. Help the test team find bugs early by providing hints in a TEST= > line. > > A good recent example is jam's change 14137: > > "TEST=added regression tests, but testers please confirm plugins on top > video sites are placed correctly." > > BUG= also helps out testers, but it also enforces the practice of filing > bugs for non-trivial changes. There should be a bug for any work that > requires more than a few hours' effort. This lets us track everything that > needs to be done to ship, it gives us a place to capture discussions of > changes, and it lets us track the status of a change *past* the checkin. > (Without a bug, we can't track things like 'testing verified that this > works' or 'this caused a regression and needs more work' or 'this landed on > the branch for Stable release X' or ''this other bug was fixed by the fix to > bug Y.') > > I really want the entire team to get in the habit of tracking what needs to > be done with bugs. It helps planning and targeting what needs to get done to > get to a release milestone. It also helps testing to determine what changes > to verify or to comment on side-effects a change might have had. > > I know that there are some cases where filing a bug seems like silly > overhead. I just asked sidchat@ to file a bug for adding a new spell check > dictionary. It will take more time for him to file a bug than it will to > make the code change. Nevertheless, the bug will also save a lot of time for > other people in the work flow from checkin to release by providing a place > to track, verify, and comment on changes. > > A good rule of thumb is "if it needs code review, it probably should have a > bug and test." Obviously, you don't need a bug to check in a build fix, > change DEPS, make non-functional changes (eg, src/chrome/VERSION), or change > only tests. > > It's a judgment call, and I trust your judgment. > > I just want to encourage you to help the people downstream of your changes > (testers, release managers, engineers fixing bugs 6 months from now) by > including a BUG and making TEST notes. > > Thanks, > Mark > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
