Re: [matplotlib-devel] All information about SF-filed bugs is inaccessible at SF

[Fernando P. <fpe...@gm...>]

Hi Eric,

On Sun, Jan 29, 2012 at 1:35 PM, Eric Firing <ef...@ha...> wrote:
> Yes, this became evident right away after the transition; in addition,
> there was a coordination glitch such that quite a few bugs that I had
> closed on SF, trying to clear out some junk before the transition, ended
> up getting resurrected on github, complete with dead links.

Got it, I missed that previous discussion.

> This is a triage situation; we have to consider the cost/benefit
> tradeoff of various ways of dealing with the mess, and with the glut of
> bug and other reports.  The fact is that we were way behind in dealing
> with the SF bugs, and we are falling behind in dealing with github bugs.
>
> I think the best approach is to be fairly brutal in closing bug reports.
>  We don't have the developer time to deal with very many.  Those that
> accumulate faster than we can deal with them merely cost us time
> whenever one of us scans the set of reports in an attempt to get the
> list under control by finding ways to close a few.

It's unfortunate that github doesn't offer a 'priority' field so that
one can threshold on it.  We use 'prio-X' labels with X in {low,
medium, high, blocker} as a substitute, but there's no way to see 'all
with prioirty >= high', for example.

But we've been trying to aggressively label everything with a
priority, and in practice only high/blocker ones really get worked on,
unless someone external shows up with a pull request for anything
below that.

My take right now is that even bugs are almost all lower priority than
pull requests: if someone took the time to actually contribute code, I
think it's critically important to get back to them with feedback.
Not having a timely review and response to a PR is the best way to
discourage potential new contributors.  My hope is that by being
pretty aggressive on that, we'll grow our developer pool enough to be
able to make some headway into the bug backlog.  One can dream... :)

> So, the dead SF links are the least of our problems; not that big a
> deal. We would lose little by simply closing all of the transfered
> reports; or at least closing all of those older than some threshold.

You're probably right, though I sort of prefer to keep an open bug if
the problem really isn't resolved.  But marking all SF bugs with
priority low (if you decide to create a similar set of priority
labels) would at least indicate this intent, and let you focus only on
the real problems more easily.  Because actually closing them raises
the risk that they will get re-reported, and then it's even more work
to start linking bugs or closing dupes.

Ultimately though, we're all (mpl, ipython, scipy, etc) suffering from
the same problem: despite the enormous growth in the user base of the
scientific python tools in the last few years, the developer pool has
not really grown at the same rate.   Our projects are have dangerously
small core teams.  I wish I knew how to change this...

Cheers,

f