Re: GSoC 2009

In that case why wasn't this pointed out last year, and I could of done something more useful with my GSoC time last year...... On Sun, 25 Jan 2009 15:05:37 +0100, sean finney <seanius@debian.org> 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