[csw-maintainers] Release process for current (was: Re: Thematics month proposal)

[Gary Law]

Dago wrote:
> There is no need for it to be handled internally.
> Explanations are given in www.opencsw.org:/home/newpkgs/README

Not sure what you mean there, but
http://opencsw.org/home/newpkgs/READMEdoesn't exist, nor does
[/export]/home/newpkgs/README on
login.bo.opencsw.org.

Trygve wrote:
>  From what I can tell the major point WRT to the release process is
getting
> every rule written down or put into code as a part of chkpkg.

+1

Peter wrote:
> It's impossible to code checkpkg to cover "everything".

This is not an argument against automated testing. Well, it is actually an
/argument/ against automated testing, but a really bad one. The whole world
of software development these days seems to have accepted that automated
testing is good, and should be used to the maximum extent possible. We
should try and code tests for every possible reason to reject a package (and
document this too).

>But there will always be exceptoins.
> At some point, there always comes a need for a human being to make a
decision
> of "yes this is acceptible/no this is not".

I disagree. If something passes all the testing, why not release it? The
project board might want to retain a long-stop power to pull software that
was defective in some previously unheard of, and therefore untested for,
way. Other than that maintainers should be able to say "this is good to go",
provided it meets the published standard. Personally, I would also restrict
this to automated builds that run off a gar or similar system, so hudson (or
similar) does the build on the basis of a published make/spec file, and the
testing/approval is fully automated.

> Peter seems to want to completely eliminate any human inspection of
packages.

There is an interesting parallel with a discussion at my workplace just this
week. Some admins want to retain manual builds for much of the software
stack. I want to see everything that can be automated. The tools are there,
and I feel the benefits are clear. It seems OpenCSW is now having the same
conversation.

> I say that this is not possible.

It is definitely possible. Do the benefits outweigh the disadvantages? I'd
say yes.

Peter then wrote:

> I tried to convey that we can reasonably cover, lets say, 80% of cases
through
> checkpkg, and 95% of cases via "written down", but there's always going to
be
> a grey area left. Either that, or our "standards documentation" will
become so
> ludicrously large, that it will become effectively USELESS

Reasons for rejecting packages need to be documented and agreed upon, not
subject to arbitary decisions. If the documentation gets too large... let's
cross that bridge then. I don't see excessive documentation weighing down
MacPorts or Fedora Packages or whatever. The "grey area" is just the
exercise of individual discretion, and we should be looking to eliminate
that from the quality control process.

Peter wrote some more:

> Decide what?
> More than one person to decide what actually gets written down as
standards?
> More than one person, in case the primary person is on vacation or ill?
> Or to play a game of "well, mom said I cant, so I'll go ask dad instead"?

The standards should be agreed on by the board at the minimum, maybe the
whole membership should vote on it.

> In my opinion, it would be a bad thing, to have one set of packages that
> are put into "current"  via one person, that have strict consistency to
them,
> and then have another set of packages, allowed to go into current
> by a different person, that did not have consistency to them.

Of course, we should strive for consistency. However, in my country, there
are many judges, juries and magistrates called upon to make legal judgements
in different courts every day. They strive to be consistent with one another
(we have Common Law system here). They may not actually be 100% consistent
but that is the aim. No one suggests that in order to maintain perfect
consistency we can only have one judge.

Sebastian wrote:
> Has the release process with Phil as the single point of getting packages
> into current shown a major bottleneck so far?

Well, depends what you call 'major'. Certainly a bottleneck.

> Or is it the manual nature (effort on the maintainers side) of the release

> process?

I don't like a manual process either. I like automation. I want to SVN check
in a fresh file to GAR, and do basically nothing else if there are no
problems... build it, test it, release to testing, wait, release to newpkgs,
maybe email me and some others a status update as it moves through the
system...

> Did packages get rejected out of uncertain or non-understandable reasons?

Yes

> Do we have a truck factor issue with Phil as the only path to current at
the moment?

We call it the 'hit by a bus' factor here, and yes. Again, personally, I
don't think packages should have a single mainainer either, it should be
minimum two. For release gatekeepers/GPG keyholders, I'd like half a dozen.

Just my 2p...

Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20090119/b715b00b/attachment.html>