![](https://seccdn.libravatar.org/avatar/bc496665c59405794cdb5236dd40ad59.jpg?s=120&d=mm&r=g)
2009/1/5 Gerald Pfeifer <gp@novell.com>:
On Tue, 16 Dec 2008, Rob OpenSuSE wrote:
So how about a more "Tick Tock" based approach, does that provide more flexibility and is it more natual?
X.0 - kernel, glibc, gcc, binutils, base utitlities, filesystems (rest feature stable, bug fixes only) X.1 (KDE) (OOo) - core stuff proven (and stabilised), latest applications X.2 (GNOME) - more application updates (FINAL release goes to retail, upgrade from X.1 & 11.1)
That would work best if upstream projects would align their releases with this schedule. If not, we might end up being woefully behind the curve in key areas, I'm afraid.
(Within any given release cycle, having such a staged approach at least as a goal certainly makes sense, and we have been doing this to some extent.)
Tried to illustrate a point simply and clearly, choosing suggested point releases based on the previous discussion. No intention to set in stone things like a total freeze on gcc, without incorporating bug fix point releases. Or preventing any kernel updates. There's not really a need for alignment, if you have release managers, making informed decisions based on the cost/benefit analysis of updating a version. And falling "woefully behind the curve" would be a strong argument for change. I see the kernel as being the main problem area there, where new hardware support is required, or changes cause a regression. For instance since 2.6.18 when libata/pata_ was introduced as "experimental", there's been drivers which consistently have problems. These tended to go unfixed upstream, as hardware with the problem generates a report, but on a production system, it uses a workround (like the older IDE ATA drivers), hardwares replaced, or machine rolls back to previous working release. Really I'm arguing for more minor releases, with smaller better focussed changes, done in a way that does get used, so that the FINAL retail release is of higher quality. Once you've been burned badly, with a 'main' release with too much stuff broken, so you could not even make clear bug reports, it acts as a huge disincentive to giving up more time on testing. The natural inclination is to avoid breaking things by experimentation. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org