Fedora Ring 0 definition

[Matthew Miller]

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 at fedoraproject.org>
Fedora Project Leader