[csw-maintainers] introducing csw-upload-pkg

[Ben Walton]

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.

> when you switch to this, virtually all packages will have no-one but
> the maintainer looking at them before release.

Broken packages will make it to unstable with the new tool, but they
do with current processes too.

> We're attempting to address the following issue > with the current
> process without reducing the ability for human QA:
> >
> > 1. Inconsistent application of policy. Multiple tools that implement
> >   different standards or the same standards differently are self
> >   defeating.
> 
> If you switch to this method, then the release toolchain, effectively
> becomes both "release manager", and "policy enforcer".

The difference from the current process being that the same checks
will be applied to every package in a consistent fashion.  And
checkpkg will only block on policy issues.

> What process are you going to put in place, to restrict changes to
> the behaviour of those things, without being effectively "at the
> whim of one person", albeit a DIFFERENT person than it has been up
> until now?

The checkpkg development happens in the open, under the eyes of anyone
watching devel at .  All maintainers have the ability to work on and
modify this code.  I've submitted (small) changes and have more in
mind presently.  These are all just adding things that people agree on
already (eg: _stub package shsould have the obsolete file).  For
actual changes in packaging standards, there should be discussion
before implementation within checkpkg.

> > All policy issues will require discussion on the list where all
> > voices are equal.  Votes will be held when required to decide
> > issues, but in many cases, we hope they aren't necessary as
> > consensus will be reached quickly.
> 
> 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.

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