On Mon, Aug 17, 2009 at 10:33 AM, Daniel Cheng<j16sdiz+freenet at gmail.com> wrote: > On Mon, Aug 17, 2009 at 9:16 PM, xor<xor at gmx.li> wrote: >> On Sunday 16 August 2009 22:36:17 NextGen$ wrote: >>> * xor <xor at gmx.li> [2009-08-16 17:33:15]: >>> > On Sunday 16 August 2009 16:38:15 NextGen$ wrote: >>> > > Hi,Being another developer who have __tried__ to fix the issue tracker, > I think I have to say something here. > > On Mon, Aug 17, 2009 at 9:16 PM, xor<xor at gmx.li> wrote: >> On Sunday 16 August 2009 22:36:17 NextGen$ wrote: >>> * xor <xor at gmx.li> [2009-08-16 17:33:15]: >>> > On Sunday 16 August 2009 16:38:15 NextGen$ wrote: >>> > > Hi, >>> > > >>> > > What are you doing here? starting an edit-war on the bug tracker? >>> > > Editing the priority/milestone of loads of tickets won't help to get >>> > > them implemented... and it is spamming our inboxes (I'm still >>> > > subscribed to most, like most of us). >>> > >>> > - People are complaining about the bug tracker being bloated and >>> > unusable, therefore I'm trying to work 1hour+ every day on cleaning it >>> > up. That is good, isn't it? >>> >>> I'm not so sure about that. Who's been complaining exactly? >> >> You for example. > > I think nextgen (and me too) think the current issue tracker is > beyond fixable and should start from sketch.
I see three basic things here: - There are a lot of non-bug things in the bug tracker. This includes minor feature requests, near-term TODO items (eg bloom filter sharing), and long-term blue-sky ideas (eg Freenet over sneakernet). Many of these are ideas worth keeping track of, even if they aren't immediately useful. Having relationships (related-to, child of, etc) between them is useful. The bug tracker provides a convenient place for them; if they're only in the mailing list archives they're hard to find and the relationships are hard to manage. However, as they're not "bugs" I can see why you might not want them in the bug tracker. IMHO the right solution is to make sure they're marked as such in a way that can easily be filtered for / filtered out. If you don't want to keep such things on the bug tracker, you need to suggest a different place to keep them. - Many of the bugs are outdated and no longer applicable, or so poorly reported that they probably can't be reproduced. Switching to a new tracker would solve this problem, but it could also be solved by going through and closing them. That's a long and boring task, but xor has taken it on. - There are a lot of bugs in the tracker that are real, well documented, reproducible, and current. Throwing these away would be idiotic. If you wanted to restart with a clean bug tracker, the first order of business would have to be going through the old bug tracker to find these and migrate them. If you're doing that, you might as well go through and mark the other stuff instead. If the issue is that you think there's some better software available for tracking bugs, that's different imho. I have no strong opinion on that matter; if the hassle of moving is worth it for better software, then by all means migrate the bug database to some other software package. As someone who is a programmer, knows what a decent bug report looks like, and has written bug reports that fall into all three categories above, I would be quite annoyed if you decided to just drop everything. That's a spectacularly rude way to treat Freenet contributors. Evan Daniel
