On 06/22/2013 03:42 AM, Robin H. Johnson wrote:
> 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.
>
Sounds cool.
I don't think we need a GLEP or council vote on that.
