Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42844
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sci.fi from 63.208.196.178 cause and error)
Message-ID: <497D942F.6030900@sci.fi>
Date: Mon, 26 Jan 2009 12:45:03 +0200
Reply-To: jani.taskinen@iki.fi
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Ilia Alshanetsky <ilia@prohost.org>
CC: sean finney <seanius@debian.org>, 
 Sebastian Bergmann <sb@sebastian-bergmann.de>,
 internals@lists.php.net
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> <8F91619F-4B28-4941-A8BA-3BC47071EA3D@prohost.org>
In-Reply-To: <8F91619F-4B28-4941-A8BA-3BC47071EA3D@prohost.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] GSoC 2009
From: jani.taskinen@sci.fi (Jani Taskinen)

See: http://cvs.php.net/viewvc.cgi/pear/Bugtracker/
That's the pear bug tracker modified for all pear/pecl/php bugs I worked 
on about 1.5years ago. :) It has that roadmap thing..

--Jani


Ilia Alshanetsky wrote:
> 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
> 
> 
> 
> 
>