Fedora Ring 0 definition

[Josh Boyer]

On Tue, Sep 15, 2015 at 10:56 AM, Brendan Conoboy <blc at redhat.com> wrote:
> On 09/15/2015 07:51 AM, Josh Boyer wrote:
>>
>> On Tue, Sep 15, 2015 at 10:27 AM, Matthew Miller
>> <mattdm at fedoraproject.org> wrote:
>>>
>>> On Mon, Sep 14, 2015 at 02:19:38PM -0700, Brendan Conoboy wrote:
>>>>
>>>> Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is.  Can we
>>>> offer a longer term of support for ring 0 than ring 1?  What happens
>>>> when a bug in ring 0 requires a fix in ring 1, but the support
>>>> window for ring 1 has closed?  That's the main thing that's worrying
>>>> about a free-for-all with self hosting.
>>>
>>>
>>> I think the main risk here, at least from a fast-moving-Fedora
>>> perspective, is that the build-dep in Ring 1 gets updated to be too new
>>> to build the Ring 0 package. (Or, less likely but possible, dropped
>>> entirely before Ring 0 support term ends.)
>>>
>>> This can be addressed by having a Ring 1 policy that packages may
>>> change, but all currently-supported Ring 0s need to be buildable from
>>> the latest Ring 1. If a Ring 1 update would be break that, a compat
>>> package would be required.
>>
>>
>> The "if" is key there.  Right now, rawhide breaks all the time because
>> people are not aware ahead of time if something is going to break when
>> they update package foo.  Without automated testing around "what
>> happens to Ring 0/1 if I bump foo", I'm afraid we'd be left in the
>> exact same state.
>
>
> As you say, this is a long standing issue.  It would be really helpful if we
> had some automated mechanism that upon rebase, all packages that used the
> rebase package as a BuildRequires was auto-scratch-built. Failure notice
> could go to both package owners.  Would this be a spamathon or genuinely
> helpful?

Opensuse Build Service has done this for quite some time.  We could
accomplish the same with some scripting and by doing builds in koji
that do not land in the buildroot by default.  Manual (or automated
after passing all checks) tagging into the buidlroot/rawhide repo
would alleviate much of the issues.

This isn't massively different than doing e.g. perl or python mega
builds in a side tag.  It would just need to be done for all packages
and with some re-education on the maintainer's part.

>>> Or, a more complicated but more flexible rule: assuming that we have
>>> multiple Ring 1s going at a time (as we currently have F21, F22,
>>> F23-branch, and F24-rawhide), there must be _some_ currently-active
>>> Ring 1 which would build every active Ring 0, but not necessarily the
>>> same one. So maybe Ring 0 version A would be slated to last through EOL
>>> of Ring 1 F25, and then Ring 1 F23, F24, F25 would all need to be able
>>> to build it, but F26 and F27 wouldn't (so compat packages could be
>>> retired if they're not needed for Ring 0 version B).
>>
>>
>> That makes my head hurt even more.  If Ring 0 can be built by Ring 1
>> A, Ring 1 B, and Ring 1 C, which is actually used to build Ring 0 that
>> is shipped?  How does one do recreatable builds across all
>> permutations of Ring0/1?  And if all permutations must be tested, how
>> is that _any_ different than just having it all in the same ring and
>> simply not bumping certain packages?
>
>
> You probably use the latest Ring 1 to build Ring 0.  That would be crazy,
> but we keep the ABI/API generating pieces in Ring 0 so it's not too bad.

Then Ring 0 is not fixed, it's just a restricted set of Ring 1.  If
you are rebuilding the foundation of your OS with newer packages every
time we have new packages in an outer-ring, you are not doing anything
fundamentally different than what we have today.

Put another way, what you suggest is akin to treating critpath
packages with a much stricter policy on rebasing but still letting
everything else rebase at will.  I personally don't see this as a ring
concept at all.

josh