Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michael Cronenworth]

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.