Wiki source for MageiaReleaseCycle

Show raw source

(saved version from )
HTML version at:

===Mageia release cycle study, by Stormi. (in progress)===
I'll try to summarize user's needs, then study various release cycles (rolling, stable + backports...) regarding those needs. Then try to propose a process which answers to most user needs while remaining realistic.

Sorry, it's quite long, because I tried to cover as much matters as I could.

===Who I am : ===
Samuel Verschelde, aka Stormi. Mandrake then Mandriva Linux user since 2004, contributed first by testing and end-user support on forums, then slowly got to packaging (after reporting more than 100 bugs on games packages, they told me "you'll get an account then fix them yourself :P"). Sometimes technically weak, maintaining few packages but sometimes doing something useful. Weird kind of packager which uses cooker only from the first beta to the final release (for bug squashing) and tries to backport packages that user's need or ask to stable releases. I try to stay close tto end-users and to listen to their needs, even if I can't answer all of them. My boss says I've got a strong sense of empathy.
I use Mandriva at home, at work (workstation) and on servers (more than 450 servers in french hospitals).
You can often find me on the #mageia irc channel on freenode.

===Vocabulary used in this document:===
~- core packages :
~~- kernel
~~- libs
~~- system components
~- environment packages
~~- Desktop environments : KDE, GNOME... They're in between core packages and non-core packages.
~- server packages
~- non-core packages :
~~- most GUI applications
~~- CLI applications which are not in core or server packages
~- (I know that things may be more complex than that, but I'm trying to split the distribution into parts for which needs can be studied separately. Don't know where to put the drakxtools for now...)

//ofaurax's comment : I think we realy need to categorize packages like this. Updating the kernel with the same rule as Firefox is nonsense.//

===End-user needs taken into account in this document:===
~- Stability (enterprise workstation, server, my grandpa's computer, or any user who just don't want anything to break)
~- Security updates
~~- core packages
~~- environment packages
~~- server packages
~~- non-core packages
~- Bugfix updates :
~~- core packages
~~- environment packages
~~- server packages
~~- non-core packages
~- Bandwidth constraints
~~- need to stay updated without using too much bandwidth
~~~- slow connections
~~~- quotas
~- Availability of latest versions of various packages, without breaking things (it ought to be as safe as possible) :
~~- core packages :
~~~- drivers-related packages : newer versions sometimes are what makes the difference between functional system and non-functional system. There's a real need for availability of :
~~~~- kernel new versions, provided (hard to achieve without an army of testers)
~~~~- driver updates (nvidia, ati, ...)
~~~- other core package : no need for version upgrades, except :
~~~~- when a package upgrade requires a lib or other core package update AND upgrading it won't break things (wise maintainer's decision and serious testing needed in this case)
~~~~- other rare situtations which I do not foresee ?
~~- environment packages
~~~- updates are often wanted (latest gnome, latest KDE), sometimes feasible, sometimes depend on non-backportable components ?
~~~- Sometimes a new version is the only way to benefit from an bunch of bugfixes (especially in KDE, where bugs are not a rare species :))
~~~- in KDE's case, environment update is needed in order to be able to get the latest version of some specific software. Don't know for GNOME.
~~~- feasible with enough man-power (packaging & testing), except maybe for first digit releases (KDE 5.0, GNOME 3.0 ?).
~~- server packages
~~~- need a more recent version than the one shipped with the release, without upgrading the whole server (eg. newer mysql or php on servers to allow web applications upgrade (real need in my job, I did the backports myself for that).
~~~- My advice : in a non-rolling cycle, prefer backporting from one stable release to another stable release, in order to benefit from the security and bugfix maintenance of the next release (e.g. in today's Mandriva php 5.3.3 from 2010.1/updates to 2010.0/backports). More recent packages (when you really need it) could be made available in testing media.
~~- non-core packages
~~~- **Those are the ones which are most needed/wanted (followed by drivers and environments)**
~~~- Latest firefox, openoffice, digikam, meld, {put any GUI software name here}.
~~~~- for new functionalities
~~~~- because very often the only way to get bugfixes is the new version (which in turn may bring new functionalities and bugs)
~- Supported backports (if we choose a stable release + backports model)
~~- support may just be providing the next release when it's ready, but for some packages may require backporting fixes if the packager is really serious.
~- For adventurous users, availability of untested (or little tested) versions of various packages.
~- Painless System upgrade when needed (be it rolling or not)
~- Long term support (LTS), at least in corporate environment (desktop : 3 years, server : 5 years ?)
~- {add more here}

===Mageia's specific needs or constraints :===
~- Buzz. New releases are really useful for that (just see all the buzz before and after each ubuntu release).
~- Manage to meet end-user needs with our limited resources (aka process optimization + of course welcome many new contributers)
~- if possible, not to use too much mirror space and bandwidth
~- synchronization with upstream important projects ?
~- {add more here}

===In what follows :===
~- I will suppose that we have the following media :
~~- main, which contains :
~~~- main core packages
~~~- main environment packages
~~~- main server packages
~~~- main non-core applications (firefox, openoffice, ...)
~~- contrib/extra
~~- non-free
~- I will not speak about **cauldron**, but only about stable releases and their maintenance once released.

===Solution 1 : full rolling release (like archlinux)===
__Description :__
Full rolling release : core packages, server packages, environment packages, non-core packages. Like cooker, but with guaranteed stability.
__Advantages :__
~- Always up to date, bleeding edge.
~- No need to know the difference between security, bugfix and new versions updates, you only update and that's all.
~- No big frightening update every 6 months
__Disadvantages :__
~- Stability / lack of choice : especially in workstation and server uses, you don't wan't new versions to be forced on you. You may want to install newer versions and must be able to do it, but you must have choice. Newer versions may be incompatible with your configuration files, with your documents (or the other way round : documents you produce with the newer version can't be opened by someone else which still uses the older version).
~- Stability again : I spoke to an archlinux user, who told me not to use it in enteprise (workstation or server), or anywhere where stability counts. A full rolling release seems only suitable to people who can fix things, or read the wiki to know when and how upgrade such or such component, because sometimes things do break. Debian testing may be better, but even there things sometimes break.
~- Tremendous amount of work in order to try to guarantee some stability.
~- Uses a lot of bandwidth. Some users can't download all those package updates they don't necessarily need.
__Discussion :__
__Conclusion :__
Not realistic. Not for a distribution which targets beginners, power-users, workstation and server and use in corporate or research/education (almost same needs) situations.

===Solution 2 : status quo (the current Mandriva Linux way)===
__Description :__
~- 6 months-schedule
~- security and bugfix updates
~- new software versions are only exceptions
~- backports for new versions
__Advantages :__
~- mirror structure identical to Mandriva's, which would ease future collaboration
~- stable and secure (but only for a limited amount of time)
~- backports bring new versions for popular software
__Disadvantages :__
~- little backport testing : no testing media for backports, so packagers often just submit the backport without anybody testing it except maybe the packager herself. This is bad for backport quality (some horror stories are already known),
~- backports are not officially supported,
~- some very useful applications not backported (openoffice), for difficulty reasons but also sometimes for policy reasons.
~- one release every six months makes 2 releases to support per year, 6 in 3 years (which is common minimal desktop life in organizations). This is really hard to support correctly, both for security, bugfix and new version updates (backports). Gives each release a very short life (support stops very rapidly and you have to upgrade to get a supported release). Example : in Mandriva Linux you can't provide backports anymore for the 2009.0 release ! It's only 2 years old and still in use !
~- frightening upgrade every 6 months, even if this breaks less often than it used to apparently (I don't know, I always reinstall in a separate partition)
__Discussion __:
__Conclusion :__
Works, but we could do better, especially on support lifetime and backports side.

===Solution 3 : "light" rolling release===
__Description :__
~- stable core packages (only security and bugfix updates)
~- stable environment package (only security and bugfix updates)
~- version updates for non-core packages
~~- openoffice
~~- firefox
~~- vlc
~~- ...
~- server packages : ? probably only security and bugfixes.
~- new distribution release every x months/years
~- backports
~~- environment packages ?
~~- server packages ?
~~- non-core packages whose stability is not sufficiently guaranteed ?
__Advantages :__
~- Stable basesystem and environment (better in this regard than the full rolling release approach)
~- Up to date most wanted applications, and officially supported, which is better than the current Mandriva way from users point of view.
__Disadvantages :__
~- No choice : you must upgrade your applications to get security updates and bug fixes. However for non-core applications, security and bugfix updates are often already mixed with new functionalities, so this may be no big deal.
~- New versions may bring new bugs. Bad for those needing perfect stability (corporate, education...).
~- New versions for non-core applications may be incompatible with your stored settings or data. However this problem is becoming rarer and rarer, and you've got the same problem with full release upgrades.
~- No rollback to old working versions in case the new version has an annoying bug (well, unless we find a rollback mechanism)
~- Still frightening upgrade every x months/years.
__Discussion :__
May work. Sexy for end-users if well done (ie no breakage). Potential stability issues on GUI apps which may make the distribution not suitable for corporate desktop.
__Conclusion :__
I don't know. May be the way to follow, or not.

===Solution 4 : stable release + supported backports (1 year cycle) + LTS===
__Description :__
~- **see also solution 5 which is the same but with a 6-months release cycle**
~- 1 release per year (so that they are less releases in use at a given time)
~~- as a counterpart, extended release lifetime (3 years, which makes only 3 releases to support at the same time. Or 2 years may be sufficient as long as there is a LTS every 3 years.)
~~- as a counterpart, release new ISOs mid-year with a selection of backports (kernel, hardware support, environment package, most-wanted applications). Community contributed ISOs or part of the mageia project ?
~~~- he main benefit would be that the mid-year ISO still comes from the same tree than the latest stable release of the distribution.
~~- One Long Term Support release every 3 years
~~- 3 years support on environment and non-core packages
~~- 5/6 years support on core and server packages
~~- upgrade from one LTS release to the following LTS release
~- updates policy : same thing as in Mandriva :
~~- security updates
~~- bugfix updates
~~- no version update except :
~~~- exceptions where upstream guarantees enough stability :
~~~~- firefox
~~~~- software with maintenance releases
~~~~- others ?
~~~- non critical packages (like contrib/updates in mandriva)
~~- novelty : new packages absent from the distribution would be not sent to backports at first, but to updates_testing (mandatory for packages in main), then updates . Then subsequent version updates go to backports. This way, new packages are made available in a default configuration, where packages are not pulled from backports by default.
~~- validated by Updates QA Team for packages in main
~- backports policy :
~~- Supported backports for packages in main (with a Backports QA Team just like the Updates QA Team for updates)
~~- As supported as possible for packages in contrib/extra (on packager's behalf)
~~- backport most wanted applications
~~~- non-core packages
~~~~- openoffice, thunderbird, vlc, digikam, wine, etc.
~~~- server packages
~~~- environment packages, whenever possible (as a counterpart for the 1 year
~~~- core packages :
~~~~- drivers-related packages (kernel, drivers...) but not without good testing
~~- supported backports
~~~- must be tested before being made available in backports media
~~~~- backport first to backports_testing, almost as soon as the package reaches cooker, if it's not too unstable
~~~~- push packages from backports_testing to backports when considered stable enough (worklow need more polishing : what does stable enough mean ? But the basic idea is here.)
~~~- bug reports, fixes, like any stable package
~~~- validated by Backports QA Team for packages in main
~~- (bonus, if feasible) easily downgrade to the version in updates or release media
~~~- however we can't do much about configuration files incompatibilities and must warn about them before downgrade.
~~- some really stable and useful backports may become official updates (provided Updates QA Team accepts them for packages in main)
~~- backports are not activated as update media in default installation, however they would be easy to install through GUI and CLI (see )
~~- improve backports visibility and our communication about them.
~~~- some ideas :
~~- bonus suggestion : at system installation, choose one from 3 kinds of updates policy (changes what the update tools propose in default system updates)
~~~- normal user (default) : only security and bugfix updates
~~~- bleeding edge : security and bugfix updates + available version updates from backports
~~~- tester : updates from updates_testing and backports_testing and reports any bugs (and at first connection, you get a "tester howto" to empower you as a good tester) (+ debug media activated)
~~~- (of course, whatever the default update policy, you will be able to install by yourself any package from any media)
__Advantages __:
~- Stable basesystem and environment (better in this regard than the full rolling release approach)
~- Up to date most wanted applications, and officially supported, which is better than the current Mandriva way from users point of view.
~- Extended lifetime because of the 1-year-cycle
~- Better backports support because of the 1-year-cycle
~- better backports testing because of :
~~- the backports_testing media
~~- efforts to empower users into testing : it's not hard to find enthousiastic users to test the shiny new version of their preferred softs, I already experienced it.
~- Suitable for corporate use
__Disadvantages :__
~- More work than in the current mandriva model : need more testers and more packagers. However this is the kind of contributers which should be easier to find than cauldron packagers. Testing is one of the easier contribution forms and is what is most required for backports (producing backports in themselves is quite easy).
~- 1 year cycle means less support for new bleeding edge hardware (ofaurax)
~~- May be true, but wouldn't the mid-year ISOs at least partly answer that concern ?
~~~- (summary of the discussion that followed (see history for full text): ofaurax fears that it would be too much work, and doesn't trust users to test the mid-year ISO enough to get a good quality). Stormi thinks that as backports would have been tested during the year that would not be that bad, that it's worth trying, even if there are still things to clarify about those mid-year ISOs.
~- Must not prevent people from contributing to cauldron, however :
~~- bugs found in backports are often bugs found in cauldron packages, so backports testing may improve cauldron's packages stability duplication and maybe even better testing for non-core, and maybe also environment, server and some core packages testing (kernels...). (I'm not saying that testing cauldron wouldn't remain necessary, don't get me wrong !)
~~- backports would be often easy to do, maybe even automated for some packages (misc once thought about that, but the lack for backports_testing media made it impossible. I'd like to push this idea further for at least a selected set of packages.)
~~- this is true also for the light rolling distro model
__Discussion :__
This is much like the "light rolling release" proposal (it brings the same advantages), but keeping the possibility to only install security and bugfix packages, and cherry-picking the new versions for the few software you really need in their latest version.
__Conclusion :__
It's the release cycle I'm proposing for Mageia (there are probably some parts to amend, but globally this is what I think we should do, or at least envision).

===Solution 5 : stable release + supported backports (6-month cycle) + LTS===
__Description :__
~- Same as above but with a 6-month cycle.
~- No mid-year release based on backports, as it would be a real new stable release
__Advantages (as compared to solution 4):__
~- More releases = more PR
~- More releases = better hardware support for recent hardware
__Disadvantages (as compared to solution 4) __:
~- More releases = more "frightening" upgrades
~- More releases = more releases to maintain at the same time, or very short support lifetime
~~- 1-year lifetime (which is very very short) -> 2 releases to support at the same time (+ the LTS release)
~~- 2-years lifetime -> 4 releases to support at the same time (+ the LTS release)
~~- 3-years lifetime -> 6 releases to support at the same time (+ LTS release on core and server packages)
__Discussion :__
I fear that with a 6-month cycle, backports wouldn't be as frequent and as well supported as they could be in a 1 year cycle (less testing for each backport because of the many releases to support)
__Conclusion :__
If the 1-year cycle were a problem, this would become my proposed solution.

===Thoughts :===
~- a "most-wanted backports" applications list may be defined by the community, or based on stats which we would then have to collect (the project may help)
~- I know that many parts of my proposal are yet to be defined before we can say whether it's the way to go or not, so please point out what I forgot or where I may be mistaken.

===Existing discussion about the subject===
A selection of some discussions around release cycle and impacts
~- answer to manage backports during the freeze of cauldron


Valid XHTML :: Valid CSS: :: Powered by WikkaWiki