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