On Tue, Sep 15, 2015 at 10:27 AM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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. > 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? I'm not sure being flexible in this instance is the right approach. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
