On 06/22/2013 11:01 AM, hasufell wrote:
> 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)
should reflect the circle of entities to do the change ... ANYBODY? Just
to not confuse it with an type of change.
>>>>>   REQUIRES_HERD
>>>>>   REQUIRES_MAINTAINER
>>>>
>> 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.
ack.

But in every single metadata? Can I get a script for my 160 personal
edits, pls?

And what's a sane default?
Let's take a amount to time (~2month) for responsive people to mark
their preferences and default to EVERTHING_GOES/ANYBODY.

And we lost the timeout dimension. An "Feel free to bump my stuff"
override in devaway works for single maintained packages, how to
interpret these data for teams and multiple maints? AWOL people...

Bottom line: I think we need more of a culture of mutual trust than a
ton of metadata.

- Respect the right of an maintainer to take a few days until responding
(except QA, security, major skrew ups),
- Honor the effort other people put into packages you don't care to much.
- Take a look at the package/ebuild complexity to estimate the
maintainers affection.
- Ask for an second opinion aka peer-review.

(And yes I've failed at every single point at least once).

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <x...@gentoo.org>

Reply via email to