# Fw:  better changeset tracking

- Thread: https://externals.io/message/29920
- Original archive: https://news-web.php.net/php.internals/29920
- Started by Steph Fox on 2007-05-30T00:32:24+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #29920 — Steph Fox — 2007-05-30T00:32:24+00:00

URL: https://externals.io/message/29920#29920

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