Hall of shame anywhere?
August 21, 2007 3:08 pm GeneralIf there would be a place where OSS folks could register most shameful things about our development process, that bug would be the first I submit. Shame on you, Firefox people! 6.5 years for a bug with that level of visibility.
August 21st, 2007 at 3:59 pm
Maybe this can help you : http://hates-software.com/ ?
August 21st, 2007 at 4:28 pm
It had zero visibility… until today ๐
August 21st, 2007 at 11:22 pm
Yes, we have a Hall of Shame — it’s called Sourceforge.
August 22nd, 2007 at 9:02 am
This is open/free source; bugs get fixed when people put effort into fixing them. I’m sure it wouldn’t take much effort to find similar deficiencies in GNOME which have remained unfixed for long periods of time, but what’s the point? The way forward for any bug is for someone who cares enough to fix it, not to gripe about it. I don’t mean to be too harsh, but your complaints are unproductive; a call for help would have been a much more useful way to see something happen in the bug.
(Also, while I’m here, a better description and set of steps to reproduce the bug wouldn’t be amiss. I’ve been involved in the Mozilla community for several years now, and even with that experience I still don’t understand what problem the bug documents, how one encounters it, and what the expected behavior is. This isn’t what’s blocking the bug’s resolution, but if someone who’s been in the Mozilla community awhile and who has used Linux mostly full-time the last couple years can’t understand what the bug is, I think that’s a pretty big problem.)
August 22nd, 2007 at 9:19 am
Jeff, thanks for the constructive comment. Regarding “putting the effort” – I think 70+ comments explaining what’s wrong, how to make it properly and even one patch contribute is some community effort, isn’t it?
I am really surprised you found the description of the bug unclear. The problem is that if you have, say, layouts en and ru configured together as two XKB groups – the shortcuts do not work if you current group is Russian. For example, if you press Ctrl-S (by “S” I mean second key on the right from CapsLock) – it does not work as “Save Page” because in Russian group that key is mapped to ะค. So, for the shortcuts to work you should always switch to en layout (or any other layout containing latin chars). There are workarounds mentioned in the comments (implemented as Firefox plugins) – but they are just workarounds. The real solution is necessary – and in the comments there are good explanations on how it is done in GTK (properly).
Does this problem make sense to you now?
I mean X Window version of Firefox, of course, – MSWin version is not affected.
August 22nd, 2007 at 9:20 am
ego, If you look at the length of CC list of that bug – you would not call it zero visibility;)
August 22nd, 2007 at 10:06 am
Oh well, nobody from Mozilla ever looks at this bug. Someone should write a patch and request review and approval from Mozilla devs.
August 22nd, 2007 at 5:27 pm
Oh, didn’t notice the patch there. In that case I think you mostly got bitten by Bugzilla’s sucky UI; it doesn’t do a good job of making it obvious how to get a patch into the hands of the right person to review it. I’ll look into this a little — we have a document on getting your patch in the tree that might work as a link on the attachment upload page, at the very least.
Also, maybe this is just what happens when your project attracts more than just technical people, but 70 comments for a bug not actively being worked on is a lot. For a bug not being worked on, I think it’s reasonable to have maybe 10-15 comments to decide exactly where the bug can be reproduced and with which steps, but most of the comments are just “me too, I see this” or “you guys should fix this!” comments that add nothing to the bug. Indeed, a bug with 70 comments is a good deal harder to approach, because anyone wishing to do so must read the bug and all the comments, being careful not to skip anything important but also being careful not to spend time reading the comments that don’t add any useful technical information. This bug has a lot of bugspam, and that makes it that much harder to use it productively; I’ve known several instances where a developer would file a bug a second time and fix it in the later bug, because he didn’t want the overhead of everyone from the first bug needlessly commenting in the second.