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