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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
