Public Bug Tracking and Open-Source Policy

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?"

Comments

MOD ARTICLE: FUD

[Anonymous Coward]

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.

This is exactly why you want to have open discussion of bugs and it represents the power of open source developement.
If this were a piece of proprietary software, you would be forced to "upgrade" and you wouldn't know about the lost feature until it was too late.

How exactly does the submitter expect OSS to work and why does he think it should work differently?
Open and honest discussion of bugs isn't something a project should have to "adapt to".
Perhaps the submitter is a lawyer and wants to bolster his declining DMCA takedown notice business?

Thank goodness...

[JustShootMe]

There's KDE... oh wait. KDE 4? Fedora? Shipping a not feature complete, buggy, and unstable desktop environment on a major consumer distribution?

Nevermind. This was actually a minor regression compared to the KDE clusterfuck.