Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29914
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.178 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=NSIjTGKch387CqkPBmjvXS1guipmldsflQNTPaoBs+UBjPtEfZHT2McxThBbexDRJD5xAPEvhN6G+yq5io/VlpW0AidWmNAmazPxWGbTs9/UmHk7K+Q2tHFzYa1o+RuRqYYYZ7NJ2CknaPK/6XtUwqo8EO+DRq2lKgr0+QOKyq8=
Message-ID: <4e89b4260705291658j554f7fcar5bf6876d4b0fdb4d@mail.gmail.com>
Date: Tue, 29 May 2007 19:58:42 -0400
To: "Steph Fox" <steph@zend.com>
Cc: internals <internals@lists.php.net>
In-Reply-To: <08e901c7a1a1$192c78e0$39dc2f52@foxbox>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4e89b4260705280856t47429e54ofcc182e02a6627e5@mail.gmail.com>
	 <00e801c7a150$d1e15690$39dc2f52@foxbox>
	 <4e89b4260705281205y50baab0k5ea109876c3c2231@mail.gmail.com>
	 <08e901c7a1a1$192c78e0$39dc2f52@foxbox>
Subject: Re: [PHP-DEV] better changeset tracking
From: kingwez@gmail.com ("Wez Furlong")

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
>
>