Tim Janik had a post about never rejecting a feature request, which got me thinking about an issue in the GStreamer bugzilla. We have a gazillion requests for support for every weird audio or video format under the sun. With weird formats I am talking about things like gameboy audio, NES audio, computer game video formats and things like that.
So these kind of requests seldom comes with patches and I tried asking for such a few times. They are also not something you don’t generally get anyone interested in helping out with, as people who just want to help out on GStreamer prefer working on something that a large numbers of users might actually enjoy, as opposed to something only the 5 person linux-based gameboy audio format community might get a thrill from ;)
So my opinion is that such features will only ever enter GStreamer if the bugreporter is interested in doing it him/herself. And if that not the case they are just ‘bugzilla clutter’.
So we are left with a situation where we have tons of stuff ‘cluttering’ bugzilla, yet it feels a bit bad closing them as they are valid feature requests and of course you can ignore the bugs by excluding enchancements from your bug search for instance (although that also filters out the more realistic feature enhancements).
Now I realize of course that the lack of gameboy audio format support makes GStreamer useless for people like Linus, and that we are fucking idiots for not diverting resources from for instance improving VoiP support over to work on supporting such formats, but in the meantime I a trying to figure out a usefull way to deal with these bug reports :)
I think discouraging people from giving feedback is a bad idea. Instead, why not mark the bug as UNLIKELY, with a note explaining that it is unlikely to be implimented without a patch.
The bugzilla priority field is severely underrated. I use it to mark things according to how important I think they are (useful to more people -> more important). If you sort your bug list by priority, the “clutter” requests should then sort towards the bottom.
As an added bonus, others browsing bugzilla get an impression of what is being/will be worked on.
I agree 100% man. Very nice post!
Suggest to change the target milestones of such bugs to ‘Future’. Then add a standard comment that clearly says the bug will receive little attention because all the developers are focussed on other things.
Do say you would appreciate someone writing a patch for it.
If you never want to implement an enhancement, also clearly state that and mark the bug wontfix; the person requesting it is of course free to implement it, but that makes it clear it will never be committed (avoids frustration).
I think the clutter bugs are best left open but I would say that since I’ve been known to file a fair few requests which fall into that category. These requests should be marked with low priority and polite disclaimers that they may never be implemented and the standard comment about ‘patches are welcome’.
if existing infrastructure doesn’t handle things perhaps a “blueskies” keyword is needed, or seperate bugstate (or mabye expand NEEDINFO to include need patches and developers for UNLIKELY to ever happen)
It is all too easy to forget that it is an effort for users to bother providing feedback and having requests marked as WONTFIX without much explanation can be very discouraging. (Having bugs marked as duplicates without copy relevant extra information across to the other bug report can be quite frustrating too.)
He didn’t call Gnomies “fucking idiots”. Read it again. He called anyone who uses “usability” as a excuse for needed features not being implemented instead of “not enough programming resources” a “fucking idiot”. The former is a dangerous practice that has been increasing in the Gnome project; the later is the responsible (and correct) response to a feature not being implemented.
I have to admit that I’m one of the people that filed a bug requesting a few of those video game audio formats. I agree with the other commenters here that such a request is kind of out there, and extremely low priority. Setting to UNLIKELY with an invitation to submit a patch sounds like a reasonable enough way to prevent them from cluttering up the Bugzilla too much.
Even though Gameboy audio (And SNES, Playstation, N64, etc etc..) support would be “great to have,” I’d rather the devs work on more important things that actually effect a measurable number of people.
Jason – the catch is, “needed features” is a mostly subjective term. Anyone can request some new features without regard to how they should fit into the existing UI – is it wrong to turn down such a request on grounds that the benefits from adding it isn’t worth the complexity it adds to the interface?
“Now I realize of course that the lack of gameboy audio format support makes GStreamer useless for people like Linus, and that we are fucking idiots for not diverting resources from for instance improving VoiP support over to work on supporting such formats..”
Attitude and (intentional?) miscomprehension are always such a potent combination.
Jason C. above summed up the issue pretty well.
And to Simon, in that context “needed features” probably referred to making commonly used/needed features (e.g. provided by hardware such a printer) available. Sane defaults are wonderful and provide usability; ability to access more advanced options is also part of usability. Someone said it much better but there is no such thing as clear majority because most people belong to some minority as well (i.e. most need some feature outside the ultrasimplified default feature set).
This doesn’t mean going all out the KDE way but widening the feature set in a thoughtful manner.
GStreamer being a non-GUI framework has different “usability” priorities and adding support for obscure formats probably isn’t a priority at this stage.