[csw-maintainers] Our core values: providing straightforward experience to the user

[Philip Brown]

A bit of a delayed reply on this one... I wanted to let it sit for a bit.
This is mostly in reply to Maciej's email, but the very last bit
addresses Peter's concerns about 'discretionary' release management.

Maciej, you made claims that resistance to package manager concerns is
because the maintainer wants to "avoid low quality"

however, the examples you give, seem to mostly be in the flavor of
"maintainer wants to avoid doing more work".


On 11/24/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>...
> A single person in power can also hurt package quality.  Imagine a
> scenario in which there is a package, which has two issues, let's call
> them A and B.  The package is unmaintained, and one maintainer takes
> on the issue A, fixes it and submits the fix for release.  The updated
> package is better than the previous one, but the release manager,
> using his discretionary powers, rejects the package, saying that the
> maintainer should fix issue B as well.  The maintainer feels he's
> being controlled, the release manager believes he's right and insists,
> and both end up in a deadlock.


point #1: notice this is nothing about the maintainer avoiding "low
quality"; this is simply about "maintainer does not wish to do extra
work".
The "feeling controlled" complaint is just a passive-aggressive way of
rephrasing "feeling pressured to do more work against his will".

Almost every argument that comes up on the pkgsubmissions list, has
nothing to do with the maintainer pushing back because it would
somehow make the package "lower quality". Nor do they even claim that.
It is almost always because the maintainer simply does not wish to do
more work on the package, and tries to argue the work is
"unneccessary".
Other types of disagreement usually get resolved relatively easily
with our existing methods.

> This kind of an issue would not happen in a consensus driven
> community.  The updated package would be released, and the issue B
> would get eventually fixed too.

 (its interesting that you assume that "consensus" means "siding with
the maintainer, against the release manager". but apart from that...)

Point #2:
In contradiction to what you claim your interest is ("promoting high
quality") your example explicitly *promotes* low quality, rather than
somehow avoiding it.
Your example says B eventually gets fixed. Which means B *is* a
problem. Which means the package is better with it("higher quality")
than without it.

Yet your 'consensus' example gets the lesser quality package released,
instead of waiting for the higher quality one to be ready.



> Phil, I understand you mean well and you want packages to work well,
> and I want the same thing.  But I believe that package quality should
> not be based on what Phil Brown (or any single person, for that
> matter) happens to think is right.  It should be based on what the
> OpenCSW community agrees on.

I'll mention that in most major free software distribution projects,
the exact opposite is true. They do not handle every package release
issue through "consensus of the members".
To take debian, as usual: (and do note that it is arguably The Most
Democratic of all distributions)
The "ftp master" team, has virtually exclusive power over what gets
released, and what does not.

Note also, that the ftp masters are not purely bound by debian policy either!
While debian policy is the usual benchmark,
"The ftpmasters also have room for discretion in applying the rules
and may reject packages for other reasons"

While complex issues may end up getting discussed on debian devel (as
complex issues with us, already get discussed on the maintainers
list!), it is in the end, up to the debian ftp masters what gets
released as a package, and what does not.