On Tue, Sep 15, 2015 at 10:51:14AM -0400, Josh Boyer wrote: > > 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. Agreed -- this goes in hand with something koschei-like for ring 0, plus Dennis' ideas for gating things, plus increased taskotron testing. > > 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, [..] > 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 was thinking: use latest Ring 1, although you don't necessarily have to cut across the day of a new Ring 1 release. And when you get to the point where a given Ring 1 will outlast (or last as long as) your Ring 0, you can use that as a line in the sand -- Ring 1s after that point don't have to care about that Ring 0 version. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
