On 5/29/07, Steph Fox <steph@zend.com> wrote:
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)
I don't see why we can't just add a field or two to the existing
database to cater to this--we've got the source ;-).
It's much simpler to have one source of ticket numbers--it's then very
clear to everyone where you go to create and maintain tickets as well
as where you go to read up on them.
Personally, I find it quite a pain to have to look in both the pecl
and php bug databases to track bugs for PDO; I'd like to avoid adding
to that pain by having yet another set of ticket numbers to reference.
Yeah that's why I said 'use the same interface'.
We can solve the problem with peons and serfs adding to the db by
using authentication, just like we do now for the developer aspects to
the bugs db.
We can, but it doesn't solve the problem that the one-line commit process would be made more painful than it currently is. Automatic addition to the database for any commit that doesn't quote a reference number would solve that. That would also mean you can't manually open a maintenance ticket even if you _are_ Jesus, as is the case with many of our folk. Still, this concept relies heavily on the idea that it's possible to append generated text to a CVS commit message, and if it isn't - it won't work.
It's the difference between a controlled environment and open source....
but I can see it working if the 'per milestone' route is taken, that's a
good idea. Anyone with QA/bugs karma care to intervene at this point?
Well, what we're really discussing here is adding some enforced
controls to our open source development. My suggestion is a pretty
light-weight modification to what we have now, and doesn't intrude
terribly on getting stuff done.
I think it _does_ intrude terribly, which is why I'm advocating automation. But others may differ.
- add a maintenance category to bug db
- add merge status to bug db
And 'no-merge'... and something like [NFM] to indicate it from scratch...
- add commit hook to detect a bug number in the commit log.
- add some method of automatically commenting on bug reports with the
commit message and urls to the diffs
Yep, my approach was relying on those additions too.
that's the basic bit to facilitate manual review.
The next step from there is writing that cron job to analyze tickets
with missing merge activity. This is easily the hardest part to
implement;
In my dream, you'd just ask the db to show all tickets with 'merge' status; everything else maintenance-wise will automatically be either closed or else marked 'no-merge'.
I'd suggest doing that last--nothing else depends on it
being there, it's just a convenience to avoid manual review of
everything, and we might find that we don't need it after all if we're
good at respecting the merge status.
We aren't :)
Maybe somewhere between both our sets of ideas there's something that'll work out without too much pain.
--Wez.