[csw-maintainers] introducing csw-upload-pkg

[Ben Walton]

Excerpts from Philip Brown's message of Fri May 06 17:22:47 -0400 2011:
> On Thu, May 5, 2011 at 10:37 AM, Ben Walton <bwalton at opencsw.org> wrote:
> > Excerpts from Philip Brown's message of Wed May 04 20:43:53 -0400 2011:
> >> On Wed, May 4, 2011 at 5:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
> >> >...
> >> > Objections to this type of automation in the past have focused on the
> >> > benefits of the human inspection that we have currently.  Nobody is
> >> > disputing that having other eyes on a package is a good thing.  We
> >> > hope that people will continue poking at the packages in unstable and
> >> > filing bug reports.
> >>
> >> "hoping", never leads to good quality process.
> >
> > Feel free to file bugs on packages pushed to future/unstable.  This
> > change will _not_ restrict the ability for humans to QA packages.  It
> > just changes the handling of the QA process.
> >
> 
> It seems that you missed.. or ignored... my point.
> but I'll save further conversation about that, to voting time.

No, I understand what you're saying quite clearly.  The 'all packages
must be inspected' argument has been your historical position on
this.  Again, nobody that thinks the automated solution is better
thinks that human inspection _can't_ help.

I happen to know that not all package submitted for release are
subjected to the same level of scrutiny though.  Some are passed
immediately without inspection.  I also know that although checkpkg
would pass a package, packages are not pushed for release.  This is
what I call a non-policy block.

csw-upload-pkg solves these problems.  All packages are equal in the
eyes of checkpkg.  They either pass policy or they don't.

Can csw-upload-pkg release bad packages?  Absolutely.  Can the human
release manager release bad packages?  See libneon.  csw-upload-pkg
has a distinct advantage in turn around for correction here as it's
not subject to time zones and sleep requirements, etc.

> >> Does this translate to,, "maciej will put in any changes as soon
> >> as he feels like it. They will be backed out, only if someone
> >> complains, AND the board agrees to put up a vote on the issue"?
> >
> > Not at all.
> >
> >> I would suggest that this is poor quality practice, and that ALL
> >> chpanges must be reviewed and approved by more than just the person
> >> coding the change.  (given that, as I point out above, the code
> >> becomes effectively interchangable with "policy")
> >
> > I think that's fair.  We already have patches flying by on devel@, we
> > could move to a SoB (signed off by), AB (Acked by) model like git
> > where at least two people must ok each change before it's approved.
> >
> 
> And what if "at least two people" like the change, but other people do not?
> Since, I repeat, this stuff becomes de-facto policy --  what
> (political/policy) mechanisms are you going to put in place to
> disallow "two people" to determine policy between themselves?

Well, most people wouldn't simply alter checkpkg (maciej's version) to
have it enforce new rules.  These would be discussed and then
implemented.  And, as development is fully open with changes sent to
the mailing list, it's easy to monitor (not that I have any qualms
about this at all).

And, if you want to get right down to it, even in your worst case
scenario above where two people collude on policy, that's still better
than the current situation where it only takes one.

> There will need to be some kind of auto-triggered dispute policy on
> this. Otherwise, two board members who collude, can do whatever they
> feel like to the code, and block votes on issues that they
> personally are against.

While I don't see this happening in the way you do, all I can say is
that the board is an elected body.  It will change over time.  Just
like any government it will make decisions you don't personally like.
Challenge it at the ballot box the next time around.

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