On Mon, Dec 5, 2016 at 2:26 PM, Matthew Miller <mat...@fedoraproject.org> 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)
> * end the .1 release support at the same time .0 ends
> * 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
My inclination is that .0 should be a no new features, only the
important bug and security fixes the package maintainers want to push.
Maybe that's not much different than where Fedora 23 is right now.
Although I sorta see an advantage of making .0 EOL about a month after
.1 comes out to get more people on .1 and then let that one stick
around a while longer after the next .0 comes out. So:
Fedora 26.0 June 2017 release EOL Dec 2017
Fedora 26.1 Nov 2017 release EOL Dec 2018
Fedora 27.0 June 2018 release EOL Dec 2018
Fedora 27.1 Nov 2018 release EOL Dec 2019
This results in an 18 month over all month cycle for the visible big
number, more stability ostensibly as well. Without changing anything
else, it'd be possible to work in a .2 release, such that it's ~7
months for each, with just a month of overlap, making it still 18
months for the big version number while still pushing some new
features.
But, I think it's also workable to keep it all to a 13 month cycle,
and EOL .0 and .1 ~7 months from release.
> 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.
To me the connotation of Bikeshed has less certainty than Rawhide, so
I'd see Bikeshed > Rawhide > major release > minor release. But
whichever order, I wonder if for sure another thing is really needed
or if the stability problems with Rawhide could be better managed with
two different ostrees: nightly vs weekly, where a semi-sane nightly
can graduate to a weekly. Or oozing vs chewy. But maybe the ostree
stuff needs more sun time itself before Rawhide could be totally
flipped over to it.
--
Chris Murphy
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
