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

["Jóhann B. Guðmundsson"]

On 11/02/2012 10:55 AM, Stanislav Ochotnicky wrote:
> Quoting Michael Cronenworth (2012-11-01 18:33:24)
>> Adam Williamson wrote:
>>> I didn't want to throw this grenade into the debate, but now someone
>>> else has, I'll just note that I was in favour of this before and I'm
>>> still in favour of it now. :) Rolling release is a model that makes
>>> clear sense for a distribution with the goals that Fedora has.
>> I've wanted to write up a blog post about my plan for a rolling release,
>> but I'll post a snip-it here.
>>
>> Fedora Rawhide - stays as is... it is a rolling release
>>
>> Fedora Feature - think of it as F18 beta right now
>>
>> Fedora Stable - think of it as F16/F17 right now
>>
>> People choose the branch level at install time. Of course, like now,
>> people can override this in the future with a change of fedora-release
>> or yum --releasever. However, per-package updates from another branch
>> level might not be something everyone can agree on how to handle, so it
>> might be wise to limit support of it at first.
>>
>> Workflow:
>> A shiny new feature is introduced in Rawhide. Things go boom. Not many
>> people are hurt by this. Once it has been given a few band-aids the
>> feature could be submitted to Fedora Feature. After some hardening and
>> polishing the feature could finally be pushed to Fedora Stable.
>>
>> I feel this should give a good compromise to everyone's fears of a
>> rolling release. It gives the feature freaks a place in Fedora. It gives
>> the stable stubborns a place in Fedora.
>>
>> I'll wake up from my dream now.
> I recently came up with similar 3-layer idea. My description was a bit
> different, something like this:
> 1. level - rawhide-like repository, more or less anything goes
> 2. level - package moves here after maintainer says "this package has been
>             working for me for some time and looks OK. Let's integrate properly
>             with rest of the system".
> 3. level - packages integrated and experience should be splendid :-)
>
> However let's see how we'd handle systemd change with this system:
> 1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd
>             as worthy FEATURE for future stable (3rd level). Packages interacting
>             with init system can take their time updating.
> 2. level - systemd moves here. After this point, packages moving from 1st level
>             here, will have to support systemd. Experience will likely be shaky
>             for a time, then settle down.
> 3. level - after some time (1 year, 2 years?) systemd moves here and all
>             packages that have been fixed to work with it as well
>
> There are several problems with this approach though:
> 1. There are always multiple big changes happening in fedora. So even stable
>     would see big updates on relatively frequent basis.
> 2. Several big changes will interact with each other. I.e. Gnome update will
>     contain some daemons so they'd have to integrate with systemd on 2nd level.
>     But then Gnome couldn't go into 3rd level before systemd.
> 3...x. a long list of further problems
>
> I am hopeful that we could make this work. Would anyone be willing to do
> analysis like this for multiple updates and play devil's advocate as well?
> Ideally trying to see how we could create processes to handle updates of the
> last 1-2 years? Because all I could come up with is: we'd end up like Debian,
> where stable is...ancient. Not that that is bad in itself if you can pick.
>

Trust me when I say this we have to fix other processes we have *before* 
we can properly fix the feature process.

Until that is done there is no point in trying to fix the feature process.

JBG