TAG | Time and tide don't wait for FOSS projects |
|
| by Sam Varghese | |
| Tuesday, 29 January 2008 | |
|
Page 2 of 2 In the case of GNOME, version 2.0 which came out in 2002 had led to a lot of frustration as it was not clear what was going on; freezes often came unexpectedly and did not lead to a release and vendors had deadlines but GNOME’s schedule was unpredictable. The introduction of a rigorous schedule and policies and the introduction of the idea of reverting - meaning that someone could be working on a feature but if it wasn't ready at the appointed time then it would be left out for the next release - meant the project gained credibility because releases were actually done on time. GNOME now has a six-month release schedule but there are doubts about whether the changes made from release to release really amount to much. In the case of the Linux kernel, a long release cycle in the past meant that many changes got accumulated. Hence features got out very slowly which led to vendors backporting many features to their own releases. The kernel team solved these problems by releasing new versions every two or three months and ensuring a steady flow of code into production - which means many people get to test the new code. In turn, this led to new features emerging sooner and hence vendors could work directly work with current kernels. However, Michlmayr pointed out that this meant there was no long-term stable version of the official kernel and regressions were often introduced between versions. He said that coordination of work needed to be a priority as a release required alignment of all work. Developers could not work on their own and then suddenly be expected to fit into a release schedule - the approximate date must be set well in advance. Michlmayr said features should not be the defining factor of a release though one could still plan for them. "You just don't wait for features in order to effect a release," he said. He listed the benefits which could accrue - organisations got a predictable schedule, users could get periodical fixes and smooth upgrades, developers would know when they had to submit their finished code, contributions would flow to users soon and vendors could plan and work with the community. "Some free software projects have successfully reacted to change (growth, users, etc.)," he said. "Time-based releases are effective because they introduce two coordination mechanisms: regularity and the use of schedules."
Get stories like this delivered daily - FREE - subscribe now
|
Tags
| < Next story in category | Previous story in the category > |
|---|
