Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42845
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Message-ID: <497D95E6.8070100@macvicar.net>
Date: Mon, 26 Jan 2009 10:52:22 +0000
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: jani.taskinen@iki.fi
CC: Ilia Alshanetsky <ilia@prohost.org>, 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> <497D942F.6030900@sci.fi>
In-Reply-To: <497D942F.6030900@sci.fi>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  Jani Taskinen wrote: > 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.. > [...] 
	Content analysis details:   (-4.3 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.1 AWL                    AWL: From: address is in the auto white-list
Subject: Re: [PHP-DEV] GSoC 2009
From: scott@macvicar.net (Scott MacVicar)

Jani Taskinen wrote:
> 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..
> 


The one Barry worked on for GSoC 2008 is at
http://cvs.php.net/viewvc.cgi/bugtracker

I've only just realised that this isn't a fork of the current tracker, I
assumed it was and had been extending the current one.

Scott

> 
> 
> 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
>>
>>
>>
>>
>>
> 
>