On Monday 17 August 2009 16:19:20 Evan Daniel wrote: > 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.
I agree with everything evanbd has said. However the main reason for a new bug tracker would be simply to save money and avoid administration hassle. We need to get rid of emu, and that means finding new hosting for our bug tracker (as well as other things such as web pages which are far more easily dealt with). Most mantis hosting options, apart from running and administering a vserver, do not support migrating existing data. A hosted bug tracker such as Lighthouse has some disadvantages but it does at least have low maintenance and might be easier to use - but we would have to migrate bugs somehow. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090817/4b675561/attachment.pgp>
