[csw-maintainers] introducing csw-upload-pkg

[Ben Walton]

Excerpts from Philip Brown's message of Sun May 15 16:14:18 -0400 2011:

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

Delaying to the point where the other parties give up.  I can provide
examples of this, but I don't think that would benefit the discussion.
Gradual improvement is a much better outcome than frustrating people
to the point where the end result is a package not released at all.

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

No, I mean that packages are blocked based on the personal preferences
of a single individual.  They are not blocked based on real defects[1].

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

The new process will not prevent you or anyone else from inspecting
50% of the packages and providing feedback/filing reports.  It will
alter the dynamics such that no single person can impose their will on
the larger community though.

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

Sorry, but no.  We made the request, yes.  You pointed at some
notes[2] you'd written previously.  I didn't follow up on it.  Unless
my memory and email history searching are faulty, I don't recall
indicating anything in either direction there.  (Corrections are
welcome, I may not have found the right threads in my mail.)

That isn't what I'm referring to here though...

Rather, I'm talking about things like changes to catalog format
(SITEFEATURES) that can be made on a whim[3] by one person while
others supported by multiple people (DATESTAMP) are dragged out
endlessly[4].

We only have one of the above changes in the catalog.

There are other examples of what I mean by 'closed' here but I think
the above highlights perfectly what I mean.

When the code is developed in the open, by any member that cares to
work on it, implementing agreed upon (functional) changes, we'll have
a good start at the required level of openness.  When we set things up
so that no single person is "more equal" we'll be in great shape.

The new tools are already fully open and available for all.  The new
work flow addresses the second issue.

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

It's good that we're voting on issues now.  I'm glad to see that in
every case changes were implemented when forced with the vote.

The problem is that we shouldn't need to force this every time.  In a
healthy situation, people would see when they're the only one against
a particular change.  That's not the case in the majority of issues
raised.

OpenCSW is supposed to be a collaborative effort.  For the most part
it is.  There is one area where the collaboration continuously breaks
down.  Time to grease the squeaky wheel.

I think the current process is broken and that the new one is a better
way forward.  I can't state it more plainly than that.

I'm going to excuse myself from the remainder of this thread unless
others raise questions or concerns that I can provide useful feedback
to.  There is no point in me reiterating my position further.

Thanks
-Ben

[1] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-May/002769.html
[2] http://wiki.opencsw.org/release-process
[3] http://lists.opencsw.org/pipermail/maintainers/2010-October/012950.html
[4] http://lists.opencsw.org/pipermail/maintainers/2011-April/014447.html
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302