On 5/29/07, Steph Fox <[EMAIL PROTECTED]> 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. 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.
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. - add a maintenance category to bug db - add merge status to bug db - 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 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; 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. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
