Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29922
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.131 cause and error)
Message-ID: <021901c7a25a$e75a4e40$39dc2f52@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Wez Furlong" <kingwez@gmail.com>
Cc: "internals" <internals@lists.php.net>
References: <4e89b4260705280856t47429e54ofcc182e02a6627e5@mail.gmail.com> <00e801c7a150$d1e15690$39dc2f52@foxbox> <4e89b4260705281205y50baab0k5ea109876c3c2231@mail.gmail.com> <08e901c7a1a1$192c78e0$39dc2f52@foxbox> <4e89b4260705291658j554f7fcar5bf6876d4b0fdb4d@mail.gmail.com> <01ab01c7a24f$27afd7a0$39dc2f52@foxbox> <4e89b4260705291810n46c89723k4059bf1d565b229c@mail.gmail.com>
Date: Wed, 30 May 2007 02:36:10 +0100
Organization: Zend Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] better changeset tracking
From: steph@zend.com ("Steph Fox")

> 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.