On Mon, Dec 5, 2016 at 9: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)
> * 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
>
> 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.
Which is fine if you have all the CI/automated testing in place to
ensure that is the case. We currently do not. Just look at the last
few weeks of rawhide based on mailing list threads. The core desktop
has issues, there was issues with ssh due to selinux regressions....
and sure all this could be gated and handled with CI and test
harnesses but we don't currently have them and I don't see enough
resources in the short term to make this a viable proposal.
Add to this you can get yourself in a situation where some core
enhancements wouldn't land in a stable release for 15-18 months! We
saw this in the F-21 cycle. For example. F-26 branches late Jan /
beginning of Feb, new feature that needs a mass rebuild (say CFLAGS
security hardening as an example) lands just after branching to ensure
max time to deal with regressions, that wouldn't land in a new stable
release until June the following year!! Now given that could have been
in development upstream for a good 6+ months before hand we could be
shipping features _YEARS_ after they're considered cool!
Now for my new role of IoT and plan to use Fedora as a base for
development you put me in a interesting situation.... I either have to
use rawhide without a history of gating and being a stable rolling
release, not ideal, or use a stable release that might not have all
the bits I need in terms of latest greatest security stuff, or I have
to allocate resources to backport that to the stable release and hope
we don't break other users in the process and spend considerable
resources in doing so.... else we fork off rawhide at certain points
that suit us based on particular features we need/want and spend
considerable resources dealing with that. Frankly none of the three
options are particularly palatable to me with the quick thought I've
put into this (I am actually on PTO and shockingly actually been AFK).
I think the proposal would eventually be doable _ONCE_ we have a
stable rolling rawhide release. I would actually really like to base
my work on rolling rawhide with ostree/atomic but only once we have a
CI/test/QE platform and gating to ensure it is a constantly stable
(sure mistakes/issues do happen) platform to base stuff on. Yes, I do
plan to have resources to assist in contributing to that functionality
but I think at the moment you're trying to put the horse before the
cart just to deal with a stats problem where you could just look at
the numbers a different way while ensuring the infrastructure to
support a proposal such as the above is actually there and usable.
Peter
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
