[Proposal] Ring-based Packaging Policies

[Stephen Gallagher]

On Thu, 2015-02-12 at 14:01 -0500, Colin Walters wrote:
> On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:
> 
> > tl;dr Shall we consider requiring a lesser package review for packages
> > that are not present on Product or Spin install media?
> 
> It's worth noting here that having two levels is not really going
> to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
> for quite a while:
> https://help.ubuntu.com/community/Repositories/Ubuntu
>
> I just have one question: You're defining this split at the *runtime*
> level.  Last I saw the Base working group was trying to cut down BuildRequires
> (but sadly I haven't seen them fighting Requires yet - I would love
>  if someone did that for Perl)
> 
> If Ring 0 packages BuildRequire Ring 1 (or further)
> packages, ultimately their quality is going to be somewhat contingent
> on them.  Using bundling as a differentiator though, it does seem
> like there's likely a lot less pressure to require quick security
> updates for BuildRequires.
> 
> Anyways, something I think is missing from here is more
> details on how this "on the install media set" distinction
> is maintained over time.  If it isn't separate (yum) repositories
> it seems like it's going to be hard to enforce.
> 

Well, it already *is* a separate repository to create the build trees,
so we always have a clear picture of what's in them. (The Everything and
updates repos are always a superset).

> (Who would notice if a package in 0 started depending on a ring
>  1?  Would that imply the new dependency needed another
>  review pass?)

We'd have to be keeping an eye on the contents of the install trees and
yes, that would require a new review pass, in my current proposal. I'd
be willing to grant a blanket exception for packages that were in the
distro up to the acceptance of this proposal (rather than only those
that were on the install media) though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150212/4beb1427/attachment.sig>