[csw-maintainers] amendments and issues with recent prop

[Jonathan Craig]

On Fri, Jun 24, 2011 at 6:42 PM, Philip Brown <phil at bolthole.com> wrote:
> 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:
>>....
> 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.
>
>

That the reality of volunteer maintainers.  I pay attention to what I
have time to pay attention which is not the same as being unconcerned
with quality.  I'm not just flopping out my own packages, I'm trying
to use the tools and documentation to turn out the best package I can.
 For me better tools that provide "code coverage" and better
documentation is what I need.

>>> 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)
>

Ah, but the reality is that I pay greater attention to list emails
that are associated with bug reports.  Thats were I really feel I can
learn something.  Package submissions are only of interest if the
package is of interest.  When I look at others packages its usually
because I'm trying to determine how they've solved a similar packaging
issue in the past.

>
>
>> 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"

If you lose your maintainer group because the process of publication
is too cumbersome then you end up with no packages.  Lack of new and
updated packages will drive away customers even faster in my opinion.

>
> 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.
>

I have no reason to believe that the core of maintainers would let
things fall that far or the belief that enforced human inspection
would prevent it.


>>> 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)

You seem to continuously ignore the reality that the proposed process
allows anyone to review any package and seek corrections prior to
publication.  IMO, this is a form of intellectual dishonesty.  You
haven't said it but from your posts I can only assume that if you
can't be the "human" in human centric then you have no wish to
participate.  You can provide the same level of human oversight of the
current system in the proposed solution.  The only difference is you
need to do it as a customer of the package maintainer instead of lord
and master.

As to human vs automated processes you are ignoring that an automated
process can apply the same level of scrutiny to every package
regardless of the number submitted.  Further, the process of teaching
the system to check our packages provides a great deal of insight into
how to improve the overall process.  Much more so than a single
individual eye balling a subset and then one-off resolving problems
with a couple of keystrokes.

>
> 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.

Your implying others haven't been honest in their portrayal of the
desired solution, while I submit you could be accused of this very
thing.  I've never said that manual inspection isn't beneficial I'm
simply arguing that a subjective inspection by a small group (or one
individual) shouldn't be a gate in the production of new packages.
Reading your email I've only seen a mild attack on my motives and an
empty complaint that the new system inhibits one's ability to critique
submitted packages.  As to support for status quo vs an automated
system I've yet to see any support beyond yourself for the status quo.
 At some point you will need to come to grips with the proposed change
an either embrace it or move on.  If you can't be vested in developing
a better automated process then I fear you will be marginalized and
left in the past.  Another victim of progress much like those who once
made buggy whips and rail against the noisy new fangled contraptions
called cars.

Again, do you honestly believe that there is insufficient support for
moving forward with an automated approach.  Once we determine this
direction, and I feel its been determined, the rest can fall into
place with all parties vested in achieving the same goal.