[apparmor] proposal - Commit Policy update

[John Johansen]

On 08/10/2010 12:49 PM, Steve Beattie wrote:
> On Tue, Aug 10, 2010 at 12:07:10PM -0400, John Johansen wrote:
>> On 08/10/2010 11:15 AM, Jamie Strandboge wrote:
>>> On Tue, 2010-08-10 at 04:59 -0400, John Johansen wrote:
>>>> I would like to update the commit policy to include a rule pertaining
>>>> to NAKs.  Basically I don't want AppArmor to have a situation where one
>>>> core dev has veto power, so that a single NAK can kill a proposed change.
>>>>
>>>> What I propose is this (or something like it),
>>>>
>>>> A NAK from a core dev should be taken with due consideration but
>>>> ACKs from two other core devs can override it if necessary.
>>>>
>>>
>>> I am going to abstain from voting but will say I feel that the commit
>>> policy should be stronger still. If a core developer has a strong enough
>>> objection to NAK, then perhaps at least 3 core developers should be
>>> required to ACK it. If this stifles innovation and/or getting the job
>>> done, we can reevaluate.
>>>
>> I'm fine with that, basically I didn't want to set the bar too high
>> as there are currently a limited number of core devs, but I think
>> 3 is a good number, too.
> 
> I'm okay with this added policy, but in general I think that we're
> all reasonable people, despite the current impassioned discussion on
> packaging policy, and that we would hopefully not need to create too
> many formalized structures to manage contributing to the project.
> I do want to ensure that we are welcoming to outsiders who are
> interested in participating in AppArmor development.
> 
yes I would rather avoid to much structure

> Basically, this policy is trying to prevent a core dev from willfully
> obstructing progress and, personally speaking here, a project that
> has a core dev that's willing to do that is not one I'm particularly
> interested in participating in.
> 
I wouldn't go this far, sometimes there are differences of opinion
that won't reach agreement.  I cases like this its not so much
about the dev obstructing the project as expressing an opion.  The
NAK is a vote against the change, other devs are free to disagree.
I would think a dev, obstructing would be persistent in fighting
against a change after it has been decided that is the way forward

I think we are all pretty reasonable, and generally I don't believe
it to be necessary, but it does serve as a statement that obstructist
behavior won't happen.

> (I do recognize that in the past I have been one of the stronger
> opponents to some of jjohansen's improvements, so perhaps I'm the
> one this policy is intended to thwart. :-) )
> 
You missed the quotes around improvements :P  Its not so much about
thwarting and ensuring that there is a statement that opinions count,
and that there is no veto.

I have hit a few too many vetos in some other projects and I just
want to make sure its crystal clear that it won't happen here.