All information about SF-filed bugs is inaccessible at SF

Hi all,

I don't know if you guys were aware of this, and if there's anything
that can be done, but I just realized that all the bugs tagged SF:

https://github.com/matplotlib/matplotlib/issues?labels=SF&sort=created&direction=desc&state=open&page=1

have useless links to their SF original pages, b/c SF has completely
closed access to the old tracker, e.g.:

http://sourceforge.net/tracker/?func=detail&aid=3044267&group_id=80706&atid=560723

I don't know if in the migration, the github issue has all the
information that was in the old bug. In ipython when we migrated from
launchpad we kept links to the old issues as well:

https://github.com/ipython/ipython/issues/13 ==>
https://bugs.launchpad.net/ipython/+bug/508971

but fortunately launchpad continues to show the original bug in full.
This is useful for a number of reasons. Launchpad is nice enough to
let you disable the bug tracker for new bug submissions while leaving
all existing bug pages still available. This is much more sensible
than what SF seems to be doing.

I don't know there's much we can do, since this is really a
SourceForge issue. But I wanted to mention it at least; if there's
important information buried in there, it might be possible to reopen
the SF tracker temporarily, scrape the bug pages for everything and
close it again. I just don't know if the orignal bug transfer process
managed to move everything or not...

Cheers,

f

Hi all,

I don't know if you guys were aware of this, and if there's anything
that can be done, but I just realized that all the bugs tagged SF:

Fernando,

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.

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.

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.

Eric

···

On 01/29/2012 10:53 AM, Fernando Perez wrote:

https://github.com/matplotlib/matplotlib/issues?labels=SF&sort=created&direction=desc&state=open&page=1

have useless links to their SF original pages, b/c SF has completely
closed access to the old tracker, e.g.:

http://sourceforge.net/tracker/?func=detail&aid=3044267&group_id=80706&atid=560723

I don't know if in the migration, the github issue has all the
information that was in the old bug. In ipython when we migrated from
launchpad we kept links to the old issues as well:

https://github.com/ipython/ipython/issues/13 ==>
https://bugs.launchpad.net/ipython/+bug/508971

but fortunately launchpad continues to show the original bug in full.
This is useful for a number of reasons. Launchpad is nice enough to
let you disable the bug tracker for new bug submissions while leaving
all existing bug pages still available. This is much more sensible
than what SF seems to be doing.

I don't know there's much we can do, since this is really a
SourceForge issue. But I wanted to mention it at least; if there's
important information buried in there, it might be possible to reopen
the SF tracker temporarily, scrape the bug pages for everything and
close it again. I just don't know if the orignal bug transfer process
managed to move everything or not...

Cheers,

f

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi Eric,

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... :slight_smile:

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

···

On Sun, Jan 29, 2012 at 1:35 PM, Eric Firing <efiring@...229...> wrote: