If you already know about the patch tracking enhancement to Bugzilla, skip to the bottom of this email to find out what's new. Otherwise, read the following description first: -------------------------------------------------------------------- I recently developed an enhancement to Bugzilla for tracking the lifecycle of a patch. The enhancement enables users to flag patches with zero or more of the following statuses: ----- "has review": The patch has been reviewed by a module owner or peer. "has super-review": The patch has been reviewed by a super-reviewer. "has approval": The patch has been granted approval for check-in during a period of added check-in restrictions prior to branching for a milestone release. "needs work": The patch has been reviewed and rejected because it needs more work. ----- Patch statuses show up in the list of patches when viewing a bug, and users can query for bugs by patch status. Other features of the enhancement include the ability to mark patches obsolete, causing their descriptions to appear with strike-through style when viewing a bug, and the ability to view all attachments on one page using a series of iframes. I also created a second enhancement to Bugzilla that makes it possible for engineers to request review, super-review, or approval for their patches by filling out a form that generates an email message to the requestee(s) and records the request in the Bugzilla database. When a requestee reviews a patch and changes its status (or submits the form without changing anything), the request is flagged as fulfilled in the database and an email is sent to the requester. Users can also view the queue of pending requests. The purpose of these two enhancements is not to create a new process for getting patches checked into the tree or to formalize the current process. The enhancements impose minimal restrictions on their use (anyone with "edit bugs" privileges can set patch statuses, anyone can make a request of anyone else), and their use is not required. The purpose of these enhancements is just to make the existing process easier to navigate and keep track of. I set up a test Bugzilla installation and filed a bug with several patches to demonstrate the enhancements: http://landfill.tequilarista.org/myk/bzpacman/ http://landfill.tequilarista.org/myk/bzpacman/show_bug.cgi?id=3 Create an account for yourself if you want to experiment. New accounts at the installation are automatically granted "edit bugs" privileges. -------------------------------------------------------------------- What's New: 1. Created a filter interface for the request queue so you can filter requests by requester/requestee login name (email address), date range within which request was made, and whether or not the request has been fulfilled. 2. Changed the "is pertinent" flag on attachments to an "is obsolete" flag (reversing the logic) so it makes more sense. 3. Removed the "has review or super-review" and "has rubber-stamp" patch statuses, both of which can be handled by the remaining flags for simplicity. -------------------------------------------------------------------- I'm gathering feedback on the tool so I can figure out what it still needs (if anything) in order to be useful to the Mozilla developer community. Check it out and let me know what you think. -myk
