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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
