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(a)fedoraproject.org>
Fedora Project Leader