[csw-maintainers] introducing csw-upload-pkg

[Philip Brown]

On Mon, May 9, 2011 at 10:28 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon May 09 12:43:00 -0400 2011:
>
>> You are essentially setting up "the board", to be the governing body
>> of policy, rather than direct democracy. Apparently, since they are
>> "an elected body", this is all right with you, over mandating that
>> policy be enforcedly fully democratic.
>
> No.  You are perceiving this only.  You misunderstood what the SoB/Ack
> was meant to accomplish and extrapolated from there.  My mistake was
> not clearly correcting you the first time.

Sounds like I should point back to my earlier email: seems like you
missed the point of what I was saying earlier.

What this system is "meant to accomplish", and what this system WILL
accomplish, are overlapping, but not strictly equal, sets :-/


> I'm suggesting that changes to checkpkg should require multiple
> eyeballs before committing.  Those eyeballs could belong to any person
> with commit rights.  Could be 2 board members or 2 random maintainers
> or a combination.  The aim here is to see that changes to checkpkg
> actually enforce agreed upon policies and removes the 'one person
> dictacting policy' you seemed to worry about.  I don't feel that this
> is a concern but addressing it doesn't hurt anyway.
>
> Any abuse is easily spotted since changes propagate to the mailing
> list.

There is "abuse", and there is "difference of opinion".
You have not laid down any foundation for smoothly resolving
"difference of opinion".
What you have written so far, only works out well for "everyone comes
to consensus on the issue".
It works out poorly, for " three people have an argument, and no-one
else cares to say anything either way" (or even cares to read the
discussion thread).


It has been my experience (and even my own behaviour), that people may
not neccessarily be bothered to read a discussion thread, but they may
pay attention if the issue is actually brought to a vote.

Not every issue is worth voting about. But some are. As such, I think
there should be some kind of official trigger for the dissenting
voice(s) to be able to start a vote on a policy/release toolchain
issue.