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). > > -- > Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Matthew Miller <mat...@fedoraproject.org> Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
