Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42846
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain barrycarlyon.co.uk from 66.36.231.197 cause and error)
MIME-Version: 1.0
Date: Mon, 26 Jan 2009 11:16:07 +0000
To: Scott MacVicar <scott@macvicar.net>
Cc: jani.taskinen@iki.fi, Ilia Alshanetsky <ilia@prohost.org>, 
 sean finney <seanius@debian.org>, 
 Sebastian Bergmann <sb@sebastian-bergmann.de>, internals@lists.php.net
In-Reply-To: <497D95E6.8070100@macvicar.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> <497D95E6.8070100@macvicar.net>
Message-ID: <f2641563fac5dde8796238d4cdfd8e4e@barrycarlyon.co.uk>
User-Agent: RoundCube Webmail/0.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] GSoC 2009
From: barry@barrycarlyon.co.uk

Decided to start from scratch....

Even tho I didnt finish it, the code I wrote has built into something
bigger which is also open source
I just didnt have time to come back to work on the bug tracker during Uni,
has and still is very busy

On Mon, 26 Jan 2009 10:52:22 +0000, Scott MacVicar <scott@macvicar.net>
wrote:
> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php