Fedora Ring 0 definition

[Brendan Conoboy]

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?

>> 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.

-- 
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.