[csw-maintainers] introducing csw-upload-pkg

[Ben Walton]

Hi All,

It's time to change the way OpenCSW packages are released.  The
current system has many flaws and inconsistencies that cause
frustration among maintainers.  Changing the process isn't a new idea.
Several proposals have hit the maintainers list in the past. What's
different this time is that there is something to back the proposal
up!  Maciej has been busy coding.  Other maintainers have been
diligently providing feedback and suggestions for improvements.  Many
of us are currently using the new process.

As I type this, it's possible to use gar/v2/bin/csw-upload-pkg to
submit your packages to the unstable catalog in opencsw-future that
sees them immediately cataloged and available for download.

At this point, the only thing lacking in the new process is the gpg
signing of the catalog.  Although this will be addressed before any
official switch to this tool, we feel that it's time to open the doors
to wider testing of the new process.

You are encouraged to kick the tires on this new tool and provide
feedback that can be incorporated to make it better.

Going forward, I formally propose that the current release system be
abolished in favour of an automated one. This will entail:

1. All packages are submitted to unstable via csw-upload-pkg.
2. After 2 weeks in unstable with no bugs filed, they are
   automatically promoted to current.

Users are free to pull from unstable directly (just as they can in
debian), but most will wait for current.  The experimental catalogs on
the buildfarm will remain unchanged as they're a good way to deliver
quick downloads for personal or bugfix testing.

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.  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.
2. An und(er)ocumented, manual process with no way to know where a
   package sits or why it sits there.
3. Subject to time availability of a single person.  (Redundancy
   exists on paper but not in practice.)
4. Packages may be stalled for non-policy reasons.

The new process will address these areas as follows:

A package that fails Maciej's version of checkpkg will be rejected.
If checkpkg is ok with it, it will be released into unstable.  If
problems are discovered by use and/or manual inspection of the
packages, a bug can be filed and the issue discussed on the list. At
resolution time, checkpkg will be augmented to catch the new problem
or the problem will be deemend 'not a bug.'

The process will be fully knowable.  The tools are open to all.  The
back end handling for everything will be fully documented[1].

Packages can be released when you're ready, at any time of day.

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.

Any and all feedback is welcomed.  Update your GAR checkouts and give
this a whirl!  Watch activity in the new catalog by subscribing to an
atom feed for the catalogs[2].

Thanks
-Ben

[1] http://wiki.opencsw.org/automated-release-process
[2] http://buildfarm.opencsw.org/~bwalton
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302