Wez,
This could work, except of course we don't have any such thing as 'a maintenance ticket' or a way to set priority to 'merge'. It's kind of the opposite way around to the way the PHP bug system works... and it probably would be a pain to have it as part of an open system (in the sense that users can add to it). Perhaps adapt the bugs *interface* to deal with maintenance tickets along the lines you suggest, but with a separate db and ID system - so we get #M9999 rather than #9999, and 'merge', 'no-merge', 'close' as the options?
If this database could take new entries directly from CVS commits (and assign a number which is then added to the commit message) it'd be ultra-workable. Anyone merging would need to quote the reference number from the original commit, but initial commits could go on as they do now. There'd just need to be a 'no-merge' code used by the committer for branch-specific changes - one of your famous three-letter tags. If the non-generated part of the commit message doesn't contain a reference number or a 'no-merge' code it gets a 'merge' ticket, if it contains a 'no-merge' tag it gets a 'no-merge' ticket (and is never closed), if it contains a reference number the ticket is closed. (This part needs rethinking if we're looking at more than two branches, but the basic idea's there.)
Would that be even remotely possible? It would mean nobody ever opens a maintenance ticket manually.
- Steph
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
