Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sci.fi from 63.208.196.171 cause and error)
Reply-To: sniper@iki.fi
To: Wez Furlong <kingwez@gmail.com>
Cc: internals <internals@lists.php.net>
In-Reply-To: <4e89b4260705291658j554f7fcar5bf6876d4b0fdb4d@mail.gmail.com>
References: <4e89b4260705280856t47429e54ofcc182e02a6627e5@mail.gmail.com>
	 <00e801c7a150$d1e15690$39dc2f52@foxbox>
	 <4e89b4260705281205y50baab0k5ea109876c3c2231@mail.gmail.com>
	 <08e901c7a1a1$192c78e0$39dc2f52@foxbox>
	 <4e89b4260705291658j554f7fcar5bf6876d4b0fdb4d@mail.gmail.com>
Content-Type: text/plain
Date: Wed, 30 May 2007 14:54:43 +0300
Message-ID: <1180526083.3496.5.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] better changeset tracking
From: jani.taskinen@sci.fi (Jani Taskinen)

Good luck forcing people developing PHP to do this or even agreeing
doing it. Laziness, do-what-I-need and chaos has been the driving force
of PHP development all the time. That works, why change it? ;)

But this is nice idea to add, having bug reports linked to cvs commits..

--Jani


On Tue, 2007-05-29 at 19:58 -0400, Wez Furlong wrote:
> We use trac as an engineering ticketing system; we open tickets to
> track things that need doing, be they bug fixes, enhancements or other
> maintenance work.
> 
> We require that every commit to portions of the repos that contain
> code reference a ticket number in trac, and reject commits that don't.
> 
> 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 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.
> 
> --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
> >
> >
>