[csw-maintainers] amendments and issues with recent prop

[Philip Brown]

On Fri, Jun 24, 2011 at 8:30 AM, Jonathan Craig <jcraig at opencsw.org> wrote:
> On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown <phil at bolthole.com> wrote:
>....
> Ah, but the bug system keeps the conversation on point.  In a mail
> list an email is likely to get hijacked into a different directions
> when you begin a philosophical debate over which approach is "best".
> That is less likely to happen in the context of  a bug report as the
> writer is conscious of the fact that this is all being filed against a
> specific instance.  And the original maintainer may not even care
> about the philosophical differences they simply need to get a package
> published so they can get some other (possibly paid) work done.

Your reply about motivations, actually aligns with what I'm trying to highlight.
A person who "just wants to get a package published", and doesnt care
about the finer points of issues... well.. doesnt care.  They "just
want to get it published" as quickly as possble, without necessarily
looking at whether it meshes well with opencsw as a whole.
It is  beneficial to overall opencsw package quality and consistency,
that someone else, with an objective eye also looks at the package.


>> 11. technical implementation issue:
>>
>>  "By opening up the QA process such that multiple people can easily
>> participate and have equal standing on the matters at hand, we feel
>> that overall package quality will improve;"
>>[...]
>
>> At the moment, a release manager is guaranteed to at least glance at
>> it. Whereas with the "new process", a package may (and I claim, will
>> *usually*) get released with no-one but the maintainer ever looking at
>> it.
>
> I glance at every release already, then I mark the email "read" unless
> its a package that holds interest to me.

It seems you are saying that you "look at the pkgsubmissions mailing
list already".
But that is missing the point of what I'm bringing up in this issue.
How many times do you actually look at the package directly?
I would guess very rarely.
Do some experimental math for a moment.
think of how many times you actually look at a package, compared to
how many are released.
Then compare to how many active maintainers we have. We'll charitably
assume that they look at "someone else's package" with the same
frequency that you do.
add up (number of maintainers) * ( number of other packages looked at /year)

Then compare that number to the total number of packages *released*
every year (we've released 754 this year so far. that does not count
upgrades to same package, so probably 800), and maybe you'll realize
then just how many packages we can reasonably predict that no-one but
the maintainer will ever look at, if they do it on an "if I'm
interested" basis.


> The automated system does allows for more/better QA as indicated
> above.  If quality suffers then we can look at this enforcement.

If no-one is LOOKING at organization-wide quality, then no-one will
realize that quality is suffering.
If you're making the assumption "if something is wrong, someone will
file a bug", unfortunately that is not true.
A package can have very bad bugs,and still no-one may report it for a
long time. Hopefully, some of the other long time maintainers will
back me up on this, if they are reading.
"no bugs filed" does not neccessarily mean "no one wants that
software". It often means "they chose to get it from someplace else,
that works, instead"



Also, once quality of a "product" suffers below some point...
"customers" tend to go elsewhere. irreversibly.
So an attitude of "well if it makes a mess, we can always fix it
later", can cause harm to the overall popularity of opencsw long term.


>> If on the other hand, the goal is really "to allow packages to be
>> released with no one but the maintainer ever looking at it", then all
>> claims about better QA should be removed from the proposal, and the
>> stated "benefits" of the proposal should be updated to reflect that.
>
> No the goal is to determine the problems and teach an automated system
> to apply this to every package, all the time.

you say "no" to start, but the rest of your post seems to resonate
strongly with an actual practice of
([you] just want to get your packaged out there, with automated checks
only, as fast as possible. Without being hindered by 2nd party checks
on it)

If so, fine, that's your opinion and wish. I believe it is the wish of
some other maintainers also. If that's' what the majority of voters
want, so be it.  I'm just saying lets be honest about what we're
voting for.