Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29915
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.183 cause and error)
Message-ID: <01ab01c7a24f$27afd7a0$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>
Date: Wed, 30 May 2007 01:12:03 +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")

Hi Wez,

> As you said, it's pretty straightforward to handle bugs this way, but
> a pain to open a ticket for every little maintenance job.  We solve
> that problem by opening up a maintenance ticket per milestone (eg:
> X.Y.Z release maintenance ticket) and use that as a catch all for
> those misc commits.
>
> When we're done with working on a ticket in trunk, we set its priority
> to merge so that we know that it is ready to be considered for merging
> down to the stable branch(es), and we close it only when that merging
> is complete.

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?

> This process should be pretty easy to translate to php.net
> development.  I'm not saying that this is the one true way to do
> development, but it works for us at OmniTI.

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?

- Steph

>
> --Wez.
>
>
> On 5/28/07, Steph Fox <steph@zend.com> wrote:
>> Hi Wez,
>>
>> >I think the key is in forcing every commit to reference a ticket; that
>> > way you can't "lose" a changeset by forgetting to put a bug number in
>> > there.
>>
>> Going back on-list... It's a good idea in principle, but I can foresee 
>> some
>> problems with it.
>>
>> Many (most?) of the unnumbered fixes Ilia's been making have been
>> alterations to internal string or memory function calls. Generally those 
>> are
>> either performance or security changes, replicated throughout the code 
>> base
>> and starting with a single 'blast' aimed at upgrading everything, 
>> followed
>> by lots of smaller catch-up fixes over the next several weeks. This kind 
>> of
>> thing isn't really worthy of a bug report, unless you have an entirely 
>> new
>> concept of what a bug might be and allow for change types like
>> 'maintenance', 'security' or 'performance' via the bug database somehow. 
>> The
>> nearest we've come to that recently is MOPB - everyone marked those fixes 
>> as
>> such - and occasionally coverity.
>>
>> If the bug db allows it it might make sense to put an initial function
>> change as a 'maintenance' report with some explanation and a number, 
>> e.g.:
>>
>> helly           Sat Feb 24 18:20:46 2007 UTC
>>
>>  Modified files:              (Branch: PHP_5_2)
>>    /php-src/main       snprintf.c snprintf.h
>>  Log:
>>  - Add [v]slprintf to overcome the returnvalues issue of snprintf
>>
>> would get a fuller explanation on the report, and every subsequent
>> "snprintf() -> slprintf()" commit would reference that maintenance report
>> number. Fine, but what to do about "malloc() -> pemalloc()"? Would all
>> 'maintenance' fixes require a test script? Wouldn't the need to check for 
>> a
>> maintenance number put devs off making a simple one-line fix?
>>
>> Branch-specific fixes are generally (but not always) marked as such at
>> present. People tend to mention it in the 5_2 branch but not in 4_4.
>>
>> - Steph
>>
>>