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

[Gary Law]

2009/1/20 Philip Brown <phil at bolthole.com>

> On Tue, Jan 20, 2009 at 10:23:33PM +0000, Gary Law wrote:
> >    OK, I have to say it hadn't occurred to me that I could ssh in... but
> I
> >    can! However, as far as I can tell the file isn't there:
> >    $ scp www.opencsw.org:/home/newpkgs/README .
> >    scp: /home/newpkgs/README: No such file or directory
>
> The original emailer, who wasnt me AFAIK, mistyped. If you actually log in
> and
> look in that directory, you will see that the actual file name is
> 00-README or something like that.


Indeed, that's it.


> Bottom line is, though, most people wont care about the file anyway. They
> will probably email me "why isnt my package released yet", and then *I*
> will go look at the file, to remind myself and them, the reasons why their
> package is still sitting in newpkgs.  I put the reminder file there
> (instead of my home dir) , as an effort to be transparent to everyone about
> what is going on with things. Go read it, if you're curious.


Thanks. That is a pointer to how things work. It is also a clear indication
of how much of this process is currently handled by one person.



> >      that is to say, automated testing is nice, but it cannot cover
> >      everything that needs to be covered.
> >
> >    Perhaps I'd have a better idea if you could explain what needs to be
> >    covered that's not automatable?
>
> Are you familiar with "the halting problem" in software design?


Err, I wasn't aware that checkpkg was actually trying to solve that problem.


> Some things are fundamentally not solvable by fully automated methods.
> This is one of them.


*What* is one of them? What are these nebulous criteria that cannot be
tested in an automated fashion -- or indeed in a consistent way by anyone
other than you personally -- but packages must comply with before release?


> If i could explain "everything that needs to be covered" before ever seeing
> it, then not only would i be capable of designing a perfect AI, but i would
> also be clairvoyant. In which case, i'd be playing the stock market, and
> relaxing on a beach in the Bahamas instead of doing this :-)


Legislators face this problem every day. So do company managers. So so
software designers. You make rules based on what you know, and what you
anticipate. You don't expect it to be perfect, do you aim for 'good enough'.
You accept that future revisions might require better rules/tests. That
'good enough' standard will be different if writing software for a content
only website, or a bank teller system, or a fly-by-wire aircraft control
system. I'm not asking you to explain everything you might find wrong in
packages that don't yet exist; but I am suggesting we need to
dispassionately look at proposed releases, against published criteria, and
ideally automate the enforcement of the standard by failing to release
things that fail a test. (I'm also not of the view that submission to one
human being for arbitrary rubber stamp based on unpublished criteria should
be the key determinant of the release process).



> >    You don't address the points concerning only having one gatekeeper on
> >    releases or on the use of individual discretion in this reply.
>
> You havent given specifics why it is a bad thing. You have basically
> stated "it is bad", without saying what is actually bad about it.
> In constrast, I have given explicit reasons why it is a GOOD thing
> (consistency), and I have also given specific reasons why the
> "phil gets run over by a bus" claim to be concerned, is invalid.
> It has already been handled.


Consistency is much more likely to be provided by automated tests, and well
understood and broadly agreed standards. One person signing things off is
more fallible IMHO. Even if you manage to be perfectly consistent with
yourself this is not a scalable, or transparent, or open way of doing this.
It does not encourage community participation. It's not a process I can
explain to a potential new maintainer. It's also not consistent when you're
not around for any reason, as the process just stops, which isn't consistent
either.

My last employer had a Change Advisory Board to decide on software releases.
We tried to keep membership consistent from meeting to meeting, to maintain
consistent decision making, but this never entirely possible. And it didn't
matter much. The fact is good (automated) QA and agreed, published standards
were more useful in the long term to raising standards in software than
trying to keep the same bunch of people in a room, week in, week out.
Companies signing off software with the potential to cost/make millions of
$CURRENCY can do so on the basis of a inconsistent process like a CAB -- so
why can't a volunteer effort release a couple of Solaris packages?


> Let's not waste people's time rehashing things that have already been
> solved, please?
>

This isn't rehashing, it's the first time I've seen it properly discussed
since OpenCSW was formed, and, from where I'm standing, this is so /not/
solved. I think you suggested putting it to a vote... something I'll be
entirely in favour of as soon as my membership application is approved.....
:)

Gary


-- 
Gary Law
Email: glaw at opencsw.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20090120/2e7b910d/attachment.html>