Public Bug Tracking and Open-Source Policy 118
Observer writes "Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy? A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature. Between Gnome's public bug tracker and similar trackers from distributions which released (and still distribute) the buggy version, months of debate provide an interesting case-study in the way front-line users and developers interact for better or for worse. What lessons can be learned here for release planning, bug triage, and marketing for a major open source project?"
Re:I hate to say it (Score:3, Informative)
OpenOffice, from what I heard of it, isn't really as much an open source app as an "opened closed source" one. I see mostly two ways development can happen: community style, like the Linux kernel, where everybody can contribute something. And core-driven, where the development team sort of throws a bone by allowing people to see the code and submit patches, but does development however they please. Outside contributors may find that something they spent a month working on is now useless, because core decided to rewrite some internal subsystem with no announcements and no discussions.
I don't think you can really use the second case to illustrate the quality of OSS development, because this sort of project management rarely differs much from closed source approaches. They might accept your patch for fixing a memory leak, but if they want Java to be required for it to work, then they WILL get their way, even if absolutely everybody else disagrees. What seems to result is that the project goes in the same direction it would have had if it remained closed, except outsiders are allowed to make minor improvements.
CVS seems a bad example, too. CVS is ancient in its design, and source control programs aren't things that can radically change their designs, because projects put processes around tools like that, and it all would break if CVS suddenly turned into Git one day. CVS' problem isn't that it has a bad development model, but that it implements an ancient and very limited design. The better systems were made after thinking on the design mistakes and limitations of CVS.
You can try Subversion instead, which is more or less "CVS done right", and removes some very annoying flaws in CVS. But it still follows the same fundamental model of revision control, so things can still be done a lot better, and it's not a drop-in replacement for CVS.
CVS is a legacy project, sort of like a Gopher browser. It can't be made much better because it's an implementation of an obsolete design, about the only thing to do with it is to maintain it.
Re:Common developer problem (Score:3, Informative)
Your prone to unfounded exaggerations, aren't you. Nobody advertised it as "use this crashproof file system!". Point me to the screenshot if you have proof to the contrary.
Also, this [livejournal.com] has already been fixed [livejournal.com] before Ubuntu 9.04, for one, is even out of alpha.
That's that, but let it be said that your other examples are at least equally inane (hint: stability without a GUI is still a valuable property).