Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29857
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: <08e901c7a1a1$192c78e0$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>
Date: Tue, 29 May 2007 04:26:07 +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,

>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