[csw-maintainers] new mailing list?

[James Lee]

On 20/01/10, 14:46:49, Maciej "(Matchek)" Blizinski <maciej at opencsw.org>
wrote regarding Re: [csw-maintainers] new mailing list?:

> It's true that in most cases it will be boring, but I think it's
> important to have the submission information available, of anyone
> wants to access it.  The problem with sendmail effort comes to mind.
> The release is one important broadcast, but a package submission is
> also an important event, if you think about the dynamics of the
> maintainer group.

No, it's not important.  No one outside the group needs to know.


> > There may be some messages associated with refusal. If broadcast and
> > 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.


>  There would be nothing the contents
> of the submitted packages.  If there was anything horribly broken
> about the package, it would be seen by the public at the testing/
> stage.

Oh yes?  If this were true no package would ever fail which isn't true,
so the initial assertion is also untrue.


> > 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.


> To recap, the boring mailing list is for visibility, traceability,
> cross-pollination and coordination, while all the lessons learned
> should be transformed into code which makes sure that the spotted
> problems will never happen again.

Visibility of what?  I'm confused as to what you think exists that
is being kept from you - and I'm not saying you shouldn't see it,
only that it obscures useful information.



James.