Am 03.09.2007 um 02:23 schrieb Alec Thomas: > On 9/3/07, Eli <[EMAIL PROTECTED]> wrote: >>> 1 Anything beyond a 'trivial' bugfix requires a branch. >>> 2 A branch must be reviewed and approved by another developer >>> before merging to trunk. If something is committed to trunk with >>> insufficient review, anyone can backout changes, preferably to a >>> branch. >>> 3 Branches should have a purpose statement on t.e.o under >>> TracDev/Branches and an announcement to trac-dev. >>> >>> Votes/Comments? > > +1. I'd have liked this process before the security merge. The > feedback > I did get, from osimons and cboos IIRC, was invaluable, but more eyes > means better code. > > Here are some more points I suggest we think about adding: > > - Requests for code review must be responded to within a timely > manner.
s/must/should :P While this is great in theory, there's really no way to enforce this. We're all volunteers here, and most of us don't have tons of spare time on our hands, so the best thing that can be done to get timely feedback is to write up a really good summary of the changes, the objectives, the design, etc. I've often found requests for review to be rather painful to actually follow up due to a lack of such documentation. Though there often was some kind of documentation, it wasn't always all that helpful. A couple of rules of thumb: * respect the time of your peers; don't write a novel; try to convey the most important points * don't assume others have looked into the problem that's supposed to be solved as much as you have; explain the problem (briefly), and explain how to ended up with the design approach you're proposing > - Purpose statements/designs should be reviewed as early as possible. In a similar vain, the prerequisite for this is that they are announced early, and are well explained. > - Feedback must be constructive, with well reasoned arguments to back > up your position. > - Each branch should contain just the changes required to implement > your proposal. This makes the reviewers life easier which in turn > makes yours easier. > > These are more just guidelines than anything but I think they're > critical to > this whole thing working. Particularly the first point. > >> It is critical that we all make the effort to review other >> developers' >> branches in a timely manner, and provide useful, constructive >> feedback >> as early in the development process as possible. > > I think this is pivotal and thus should be included in any policy. > Having a well defined process is a good idea, but the true change > that's > needed is constructive, in-depth, early review of design proposals and > branches. +1 with Alec's additions. These rules and guidelines should go on a wiki page in the TracDev space. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
