On Fri, Jun 21, 2013 at 09:06:30PM -0400, Mike Frysinger wrote:
> On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote:
> > On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote:
> > > > I'm not going into review systems here at all, I'm simply trying to
> > > > have a policy of what changes are welcomed/blocked WITHOUT interaction
> > > > from the listed maintainer(s) of a given package/herd.
> > > 
> > > add a new field to metadata.xml that declares the state.  make it an enum:
> > >   ANYTHING_GOES   (the default)
> > >   REQUIRES_HERD
> > >   REQUIRES_MAINTAINER
> > 
> > I wish it was that easy.
> > 
> > Despite being ANYTHING_GOES on most of my packages, I don't want people
> > to add giant features like qmail patchbombs; so we need to figure out
> > something like the Debian NMU listing of what's acceptable.
> the maintainers intent has to be machine codable
So we have the following facets of NMU permissions:
Who
What

> > Does a version bump count as an acceptable trivial change?
> that's up to the maintainer
This needs to be in the above data:

So we have:
Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}

So most of my packages might be coded with:
<nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
<nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />

- If you're a developer, you can do trivial fixes, add minor features,
  bump the version.
- If you're in the herd, you can add major features.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Reply via email to