Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 74.125.44.28 cause and error)
Cc: Sebastian Bergmann <sb@sebastian-bergmann.de>,
 internals@lists.php.net
Message-ID: <8F91619F-4B28-4941-A8BA-3BC47071EA3D@prohost.org>
To: sean finney <seanius@debian.org>
In-Reply-To: <20090125140537.GA11470@rangda.stickybit.se>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Sun, 25 Jan 2009 13:59:00 -0500
References: <57312195-1B2C-44C1-9FCC-A699AFF9B6A7@macvicar.net> <497A388E.4050907@gravitonic.com> <bad2d1f8ef6707631ca2250a9263812a@barrycarlyon.co.uk> <7f3ed2c30901231535l12ae7b64l41e01a9207b73e4a@mail.gmail.com> <glebu4$tdp$1@ger.gmane.org> <01CEBD65-4E72-4254-9AF4-8D8A4446300F@prohost.org> <20090125140537.GA11470@rangda.stickybit.se>
Subject: Re: [PHP-DEV] GSoC 2009
From: ilia@prohost.org (Ilia Alshanetsky)

Sean,

You make some very good points and I'll be the first to agree there is  
definitely a room to improve the existing bug-tracker, in particular  
its integration with the repository commits, but I do not think it  
needs a fundamental rewrite. From what I can see most (I think its  
all, but being careful with generalization here) developers already  
put "Fixed bug #..." in their bug fixing commits. I would be fairly  
trivial to add a regex to grab those and automatically close the bug  
report and even add a link to the diff. As far as branch fix tracking,  
it could be as simple as adding another SQL table to the bug tracker  
along the lines of:

CREATE TABLE bug_fix_revisions (
bug_id integer not null,
branch varchar(25),
date timestamp
);

We could then add another search page to bug tracker that will give a  
you a matrix of all the fixes performed between date X and Y looking  
something like this

BUG # | Branch X | Branch Y | Branch Z | ...
1223    |   (date) | (date) | | ..

It would solve your problem, I think and would make RM life easier in  
terms of tracking fix syncronization


On 25-Jan-09, at 9:05 AM, sean finney wrote:

> hi everyone,
>
> On Sat, Jan 24, 2009 at 11:40:08AM -0500, Ilia Alshanetsky wrote:
>> I think our bug current tracker is pretty good and most importantly
>> makes it easy to report and update bugs which is conducive to more
>> issues being reported. Often extra features of bug trackers make them
>> overly complex to use and people just get frustrated with them and  
>> don't
>> report bugs as the result.
>
> aplogies if what comes is just a little verbose...
>
> for those who don't have the luxury of "building from the latest CVS
> snapshot", the current tracker is sorely missing some kind of better
> integration with your version control system.
>
> by a couple orders of magnitude the largest amount of time i spend on
> maintaining the debian php packages is the result of going on treasure
> hunts through your cvs logs and commit lists trying to find just which
> commits map to a particular (usually security vulnerability) bug, and
> then making sure that there were no regressions in the fix addressed  
> by
> later commits.  take the last issue with the Zip::extractTo()...
>
> while you might not consider my request important enough to address
> (i.e. "we don't support 3rd-party distros so we won't go out of our  
> way
> on this"), this has implications for intra-project issues as well.
>
> for example, when a bug affects multiple branches, those doing RM work
> would probably be interested in knowing that the fix was applied to  
> each
> of the relevant branches.
>
> while i'm sure there are more technical ways of integrating support
> for this, one very easy way is to just map CVS/svn/etc commits to bug
> reports transparently.  if a commit contains something like '#nnnn' in
> the commit message, you could have it post the commit info to the  
> tracker.
> then a quick read of the bug report should be the only thing necessary
> to know if each of the branches have recieved a fix.  and as a side
> effect it would also solve the problem for those of us who
> package/distribute php externally...
>
> anyway, sorry if this is hijacking the thread just a bit, but having
> just spent a large part of my "free time" doing some of this stuff,
> i felt compelled to throw this in.
>
>
> 	sean

Ilia Alshanetsky