Ian Malone wrote:
How does this work with things like Anaconda? In a rolling model
(assuming you can do other major upgrades without reinstalling, if not
there's less point anyway), people aren't going to be reinstalling so
it could easily trickle through to stable before getting serious use.
Installer images could remain at a 6 month interval, or change to a 12
month interval, or be spun after a major feature reaches one of the
branch levels. There is more flexibility in a rolling release model to
ship a installer image.
The QA group would retain their duties in testing as they do so today.
In fact, it might make QA a stronger group as today they can only focus
on Rawhide/Branched releases. Very little QA time is spent on N+1 or
even N releases. Lacking a "version" tag doesn't mean things will go
untouched. The only way features would advance down a branch level is if
they received approval from FESCo/QA.
How does it work with major changes like UsrMove? It might never have
been done...
How does it [something similar] work with Gentoo or Debian? :)
In the case of major file system changes, and not just package updates,
a distribution upgrade tool (fedup?) would be required. Yum would need
to gain the smarts to see "distribution updates" as well as regular
packages. Such a feature existed on my Nokia N900 phone (Debian) to
upgrade it to new major releases without reflashing or command-line usage.