Fedora Ring 0 definition

[Brendan Conoboy]

On 09/15/2015 07:27 AM, Matthew Miller 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.
>
> 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).

Either of these seem possible.  It's also reminded me of another "why 
rings" and "why split the OS out?" answer: Because it might be 
possible to move to a branch-per-major-version model instead of a 
branch-per-release-model for the non-OS components.  Serious retooling 
for that one, of course, but it'd be neat.

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