[csw-maintainers] introducing csw-upload-pkg

[Philip Brown]

On Sun, May 15, 2011 at 11:56 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Wed May 11 19:55:35 -0400 2011:
>
>> In legal, and corporate circles, this is what is known as a
>> "conflict of interest".
>
> If you consider this change a conflict of interest, you must see the
> irony in the current release manager arguing for status quo. :)


not at all. This is not a case where the person(s) controlling the
flow of "product", also controls all means of complaint and redress.
I have shown multiple times as release manager, that in the existing
process, the recourse for redress, is a vote, and I have abided by the
results of the vote in all cases.




> I don't see the conflict here.  I'm pushing for what I believe to be a
> better process.  As things stand currently, there is a single person
> capable of preventing package release.

As I have just pointed out, the single person is ultimately only
capable of DELAYING, not preventing, a package release.


>  This is done far too often for reasons other than policy.

I think this would be more accurately stated as, "you disagree with
the reasons for it".
Written policy does not and cannot cover everything, so complaining
the reasons are "outside policy" is non-productive.

>It is inconsistent.

no-one is 100% consistent. A better question is whether overall
quality is higher with it, or not.
A process that adds higher quality to a random 50% of the packages,
but does not touch the other 50%, is still valuable to have, not
withstanding that it is "not consistent".




> It is handled by closed tools and processes.

untrue. And as a board member, that is tantamount to lying, since what
other members dont know, is that previously, the current board
requested documentation and disclosure of all processes related to
release. Which I complied with, and you all agreed I had complied
with.


> When many people want things a certain way but one doesn't and that
> one can block packages, there is a glaring deficiency.  We're
> addressing this problem.

it already has been addressed. multiple times, as mentioned above. A
vote on the specific issue can always be taken.
This seems more about maintainer impatience than anything else.