[csw-maintainers] new mailing list?

James Lee james at opencsw.org
Thu Jan 21 11:50:06 CET 2010


On 21/01/10, 00:27:21, Sebastian Kayser <skayser at opencsw.org> wrote
regarding Re: [csw-maintainers] new mailing list?:

> >>> recorded by a mailing list there is the potential for public
humiliation.
> >
> >> Humiliation of whom do you mean?
> >
> > Presumably the idiot that submits a sparc package with intel binaries.
> > If you are not embarrassed to submit packages with such fundamental
> > mistakes your standards are low.

> Could we please just drop the harsh word "humiliation" (and the attitude
> that usually comes along with it wherever one ventures)? There is always
> something to learn, everyone makes mistakes from time to time and those

No, it is used on purpose to emphasise my point.  People make mistakes,
we know that, we accept that.  What is not useful is to make a list of
someone's short comings and put them on a advertising billboard.

> who are learning should _not_ feel like they are at the eager eyes of
> those who know better and who are just waiting to humiliate them.

Exactly my point, glad you agree.


> >>> Any useful information should be condensed from the flow and put on the
> >>> maintainers' list or a "How (not) to make a package" web page.  I'll
> >>> start here with common problems and top tips:
> >
> > ...
> >
> >> Everything that can be automated, should be automated.  Documenting
> >> isn't a bad idea, but the things you've described above, thinking
> >> aside, are mundane and boring.  Doing them each time for each package
> >> is a waste of braincycles and keystrokes.
> >
> > Yes it's boring and mundane.  Please explain why someone else should
> > do this for you?  More importantly why I have been.  You seem to not
> > understand anything about the effort involved in QA.

> >From what I understand, Maciej tried to point out that if something is
> "boring and mundane" and can be automated, why not let's do it and save
> everyone's braincycles and keystrokes, especially yours and Phil's. He
> also offered a hand at extending checkpkg so that it can catch more of
> those commonly encountered issues. I doubt very much that he doesn't
> appreciate what the two of you are doing.

Automating in only part of the story.  People have repeatedly suggested
automation is the answer to everything, well firstly much of my test *is*
automated.  This is not the hard (boring and mundane) part, what takes
the time is understanding the output, moderating the marginal cases and
effecting rectification.

Secondly if you have a automated test procedure that installs a package,
answers questions, reads the readmes and follows any instructions as
a human would then uses the software and finds all errors please present
it.



James.



More information about the maintainers mailing list