On Mon, Dec 5, 2016 at 4:26 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
> On Mon, Dec 05, 2016 at 01:43:58PM -0700, Chris Murphy wrote:
>> I'm not sure it's much harder to do without modularity. Right now
>> Fedora could do a Fedora 26 release without any conventional release
>> media for server and workstation, by just using dnf system-upgrade and
>> gnome-software. And in a sense that's more like how the incremental
>> release for rpm-ostree based installations end up working out anyway.
>
> True.
>
>> Would Fedora 26.1 be a branch off Rawhide, or a branch off Fedora 26
>> with relaxed rules about what sorts of things can be significantly
>> updated? A huge part of the effort for each release is sun baking the
>> rawhide. And what effect does a once a year major release have on
>> Rawhide? Or what effect do we want it to have?
>
> I was thinking a branch off of 26 with relaxed rules. I'm not sure what
> the EOL policy would be like — could be any of
>
> * treat both .0 and .1 releases as we do full releases now (which would
> make each release go EOL a month after the *next* .0 or .1)
I don't see how this is different from today other than naming.
> * end the .1 release support at the same time .0 ends
That would seem to break common expectation that point releases extend
lifecycle. Not the end of the world, but clearly we'd be deviating
from the rest of the software world.
> * make the .1 point a big update bundle and not support .0 after that,
> but taking the whole thing around to after the next .1
That seems the most tenable position.
There is another problem with .0...N releases. As soon as you version
your main release like that, everyone assumes .0 is unstable or broken
and they wait for .1. Some wait for .2 (which doesn't exist in your
proposal but clearly could). This is a perception problem more than
anything, but it exists and is quite common. In products that have a
multi-year lifespan that isn't ideal but it also isn't the end of the
world. It just means your adoption curves look similar to Fedora's
today and the end result is that the majority of your users are
migrated when that release is well into its support lifecycle.
In a Fedora world, it means your .0 release gains limited adoption,
with .1 being more popular (OK so far), but then M.0 comes out in 6mo
and you reset. Essentially you've adjusted your adoption rate to
spike on the .1 updates, and artificially limited the userbase of that
major release. That in turn limits the testing and deployment
opportunities which limits the fixes you can get into .1 to make it
better. I'm not sure that's a net win.
> Rawhide is a good question. I'd like to see the more-stable-rawhide
> ("Bikeshed!") idea in place, and hopefully more people running that,
> making it more likely that Rawhide is at a good place for stabilization
> when we branch for the annual release.
The simple answer there is that Rawhide becomes your (gated) rolling
release, and the releases deviate from it by stability and lifecycle.
This is essentially what SuSE has done with Tumbleweed and Leap,
respectively.
josh
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
