I was reading http://live.gnome.org/GnomeGoals just now, and a thought struck me. I know that for some people (particularly admins) the six-monthly release cycle of GNOME is too frequent. They have just managed to iron out the issues with the last release when the next one comes along. How about devoting every second "release" to bug fixing and documentation?
Imagine what six months of bug-report and patch reviewing (and, of course, bug-fixing) would do for the quality of GNOME. Think TeX.
Remember kids: users don't really want features. They just want their software to work. (If you really must implement a new feature, please consider doing so by a plugin framework rather than monolithic releases.)
Thoughts, anyone?
Subscribe to:
Post Comments (Atom)
Posts
16 comments:
I have been thinking im my mind that something like this needs to take place. Especially if we are ever to go 3.0
What if we had a 1 year cycle, however 4 months of the cycle are feature freeze, so we can get the bugs ironed out.
A less fequent schedule will make people think we are doing alot more.
Imagine for instance there was no realease between 2.2 and 2.14 - a 3 year gap, people would think we have done as much as msoft with vista, but alas our incremental improvements are not viewed as anything substansial.
I like the idea personally. I tend to use some slower-to-adopt distributions. When I find errors in docs or some such I tend to assume there's no reason to contribute because the mainline is so different.
The trouble is that developers like adding features, whereas fixing bugs can quickly become tedious. Some people are cut out for doing documentation, others for being walking, talking program-breaking bug-finding scripts, and so on. This is why people sometimes like the "odd-unstable" system, but that often means the stable (even) releases get a little neglected, even though the six months after release they ought to be supported with bug fixes. I think backporting is the key word here - both bug fixes to distable releases, and updated stable versions to distributions (I like Ubuntu, but the fact they stick at a single upstream version regardless of whether it's a bugfix-only stable tree or not hinders my enjoyment of its packages)
I think you missed the fact that many GNOME developers are not getting paid for their work. they do need some fun, and bugfixing only is no fun.
they'll develop no matter what they say. they'll make a branch in which they'll develop new features, and this branch will be released after 1 year instead of after 6 months and therefore will have gotten more changes in that time and so will bring more bugs. then, yes, it will need the full 1 year to be completely debugged.
to summarize, i think your idea assumes too much and simplifies too much. could work in a corporate setting, where employees are paid, though.
Fantastic idea, unfortunately as some have mentioned it probably won't happen.
John, I have 2 questions:
1) What modules are we talking about here? core GNOME platform or general GNOME-related software?
2) Is your experience based on talking to users or talking to developers?
Because if you're talking about core GNOME modules and about its maintainers, I think the people are not doing much more than bugfixing. I can't speak about everyone here, but in the modules I'm somewhat involved with (gtk+ or the panel), there's not much else than bugfixing going on. Bugfixing in this case means working on often reported bugs or just applying patches from bugzilla that have been written by other people and waiting in bugzilla for some time (sometimes more than half a year). This is a tedious process, because you need to ensure such changes never ever crash (patch-review in those products is very rigid compared to other products), don't break current behaviour, work on X different platforms, are in line with the HIG, implement specificatios correctly and so on. I've spent more time on getting a patch to rework drag'n'drop in the panel accepted by Vincent than on writing a game, that has about 10x as much code.
I certainly don't see maintainers spending their time doing "useless" feature work. Even such a big "feature" as printing in Gtk is nothing more than fixing a lot of highly visible bugs in GNOME applications that people complained about. Especially since most of the work was done by someone who is not a Gtk maintainer, so it was again "just" applying a patch for the maintainers.
What I can see however is maintainers not spending enough time on their modules. There are various reasons for this. The products may be very big so the current amount of maintainers is not enough (see Tim Janik's mail about gtk) or the current maintainers have to devote their time to other things (boss wants them to work on other stuff, or students need to study). It would be nice if there were more maintainers that had commit rights to important modules, so the current maintainers weren't bottlenecks for more frequent patch submitters as it would make the development of those products faster and/or free up some time for the current maintainers. However, if those people didn't have the same (read: different) quality standards as the current maintainers, I could see that reducing the very high quality we expect from those products. I have no idea though. Food for thought
Good comments. I'm inclined to agree with the view that developers want to work on new funky stuff rather than to stabilise existing stuff. Not only that, but there is an element of "keeping up" with the other platforms - Vista is coming along and people will "expect" GNOME or whatever desktop to have equivalent (or better) features.
Bug fixing and stability is always good, though...
I am not sure if users just want their applications to work. Why do they upgrade then or buy new computers?
Maybe 2 months more time per release would be just fine. 4 months to squeeze the features in and another 4 months to squeeze the bugs out. Or 2 months for major features, 2 months for a "quick" cleanup, another month for minor features and the remaining 3 months for polishing.
I'd like a pony!
"(If you really must implement a new feature, please consider doing so by a plugin framework rather than monolithic releases.)"
Thereby increasing the changes for strange unreproducible bugs therefore increasing the cry from people with no clue for eternal bug fixing.
Do you know what you're actually talking about, or do words you like the sound of just get strung together? Seriously, feel free to prove me wrong and do it yourself if you feel its so important.
Meanwhile, the developers will be over here doing something useful
As others have said, this has been brought up before. The latest attempt can be found at:
This link
FWIW, I, and virtually all the doc team, would love to have more time. If you want to pick up the batton and try again, you'd get my support at least.
I also like your idea - but I have to disagree on the "users don't care about features".
I would suggest using a cycle or two to get rid of as many bugs as possible from the actual platform and while doing this and potentially preparing the 3.0 platform, 3.0 development could already take place. from looking at GNOME today the one thing I would like to change is the panel... which could really use a complete rewrite.
I totally agree with the post. The nature of open source development means that features develop naturally quickly, but it takes effort and discipline to ensure that the benefits of having open source software lead to stable software which will work on computers which are 2 years old. Currently, my feeling is that GNOME doesn't quite get the balance right. It's not bad, but it could be better. GNOME point releases have lots of good work going into them, and focusing and building on that would be of real benefit.
It's all very well to say that contributors to free software need to have fun, but I hope that lots of them are motivated by a will to produce software which rivals proprietary software, and this suggestion would improve GNOME's changes of achieving that goal.
The more aggressive release cycle is needed because each release isn't just new features, but it's generally UI usage and refinement which is more important to users, since they can actually figure out how to use their interfaces.
I'd say that the opposite applies: Short release cycles *improve* a software's quality because they force the developers to settle on a stable version at frequent intervals.
Post a Comment