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
