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 <sc...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
