|
Rockbox mail archiveSubject: Re: question about tracker e mails to the listRe: question about tracker e mails to the list
From: Paul Louden <paulthenerd_at_gmail.com>
Date: Sat, 21 Jun 2008 09:57:39 -0500 Antony Stone wrote: > a) close down the list if they don't intend to do anything with the ideas > expressed there > The way you've phrased this, it sounds like somehow someone's obligated to follow up on feature requests. Even if we never, ever, ever intended to do anything about them, wouldn't they possibly still be valuable as a repository of ideas for new people interested in working on the project? > b) respond to the posting which are deemed "pointless or crappy and will never > be implemented" so that at least people know that, and they don't hang around > for years as open requests on the list. > > We do this already, the problem is there are many, many, many cases where, for example, I think it's a crappy, horrible, terrible idea but I know I shouldn't reject it outright simply because it's not my project and while I don't like it, maybe I can at least voice my concerns so that if someone does work on it, it finds its way in in a manner that's at least more suitable, and helps make more people (on average) happy. > On a similar vein, I can't quite work out what the system is for the bugs > tracker - once someone has posted a bug and confirmed the circumstances and > how to reproduce it, is there any mechanism for scheduling a fix into the > workstream, How would one schedule anything with volunteers? In a ExampleCo, you can say "You work X hours a day for me, and while you're here, you'll be working on this." In Rockbox, if Bob McDemonstration usually works 8 hours a day on Rockbox, and someone said "While you're working on Rockbox, we want you to be fixing this bug, because you probably know the most about it" all that will happen is that days he's not interested in tinkering with a hard to find bug, he'll work on Project Widget instead. > or allocating the fix to someone who knows that part of the code, > etc? I know this is an open source project run by volunteer developers, and > nobody can be told what to do, but I'm just wondering what mechanism is used > to try to get action on confirmed bugs which are in the system? > > Firstly, many "confirmed" bugs aren't as confirmed as the authors think. Reproducing on the author's side is the first step, but in many cases they can't be reproduced on the developer's side. Even then, if the developer can trigger it regularly, it's often not obvious at all where in the code the actual problem is. Obvious bugs rarely stay around for long. As for assignment, the assignment system is actually a way for a developer to say "Hey, I've looked into this, I have an idea, and I'm working on a patch. You can work on one too, if you think you can do it better/faster, but you don't need to waste your time on it. I've got this one." Except in exceedingly rare circumstances, it should really only be used by someone assigning something to his or her self. Received on 2008-06-21 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |