Good luck forcing people developing PHP to do this or even agreeing doing it. Laziness, do-what-I-need and chaos has been the driving force of PHP development all the time. That works, why change it? ;)
But this is nice idea to add, having bug reports linked to cvs commits.. --Jani On Tue, 2007-05-29 at 19:58 -0400, Wez Furlong wrote: > We use trac as an engineering ticketing system; we open tickets to > track things that need doing, be they bug fixes, enhancements or other > maintenance work. > > We require that every commit to portions of the repos that contain > code reference a ticket number in trac, and reject commits that don't. > > As you said, it's pretty straightforward to handle bugs this way, but > a pain to open a ticket for every little maintenance job. We solve > that problem by opening up a maintenance ticket per milestone (eg: > X.Y.Z release maintenance ticket) and use that as a catch all for > those misc commits. > > When we're done with working on a ticket in trunk, we set its priority > to merge so that we know that it is ready to be considered for merging > down to the stable branch(es), and we close it only when that merging > is complete. > > This process should be pretty easy to translate to php.net > development. I'm not saying that this is the one true way to do > development, but it works for us at OmniTI. > > --Wez. > > > On 5/28/07, Steph Fox <[EMAIL PROTECTED]> wrote: > > Hi Wez, > > > > >I think the key is in forcing every commit to reference a ticket; that > > > way you can't "lose" a changeset by forgetting to put a bug number in > > > there. > > > > Going back on-list... It's a good idea in principle, but I can foresee some > > problems with it. > > > > Many (most?) of the unnumbered fixes Ilia's been making have been > > alterations to internal string or memory function calls. Generally those are > > either performance or security changes, replicated throughout the code base > > and starting with a single 'blast' aimed at upgrading everything, followed > > by lots of smaller catch-up fixes over the next several weeks. This kind of > > thing isn't really worthy of a bug report, unless you have an entirely new > > concept of what a bug might be and allow for change types like > > 'maintenance', 'security' or 'performance' via the bug database somehow. The > > nearest we've come to that recently is MOPB - everyone marked those fixes as > > such - and occasionally coverity. > > > > If the bug db allows it it might make sense to put an initial function > > change as a 'maintenance' report with some explanation and a number, e.g.: > > > > helly Sat Feb 24 18:20:46 2007 UTC > > > > Modified files: (Branch: PHP_5_2) > > /php-src/main snprintf.c snprintf.h > > Log: > > - Add [v]slprintf to overcome the returnvalues issue of snprintf > > > > would get a fuller explanation on the report, and every subsequent > > "snprintf() -> slprintf()" commit would reference that maintenance report > > number. Fine, but what to do about "malloc() -> pemalloc()"? Would all > > 'maintenance' fixes require a test script? Wouldn't the need to check for a > > maintenance number put devs off making a simple one-line fix? > > > > Branch-specific fixes are generally (but not always) marked as such at > > present. People tend to mention it in the 5_2 branch but not in 4_4. > > > > - Steph > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
