[csw-maintainers] new mailing list?

[Maciej (Matchek) Blizinski]

On Wed, Jan 20, 2010 at 12:25 PM, James Lee <james at opencsw.org> wrote:
> I guess the majority of new package emails are "here is a package"
> followed by "thank you" which anyone can infer happened by the pattern
> of releases.  Actually we don't know if it happened and neither does
> it matter as the important event is release which is already broadcast
> and public.  Any useful transmission will be masked in a stream of
> boring traffic.  Subscribe?  No thank you.

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.

> 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?  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.  This rules out the mailing list as a humiliation cause.

> Brilliant idea, this might cause people to think before submitting a
> package!  Can we have a naughty step on the web site?
>
> 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:
>
> 1. put the right arch binary in the right package
> 2. use the package for several days before release, install with pkg-get
> 3. remove your package (important as can't fix after install)
> 4. check that the new package does not disrupt any dependants, eg
>   by changing a library's SONAME.
> 5. think.  Eg in the package dir, run:
>      find . -type f | xargs file
>      find . -ls   (look at locations and sizes)
>      find . -type f | xargs file | nawk -F: '/ELF/{print $1}'
>         and on each result:
>            dump -Lv ...
>            ldd -r ...
>   and think.

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.

Having a maintainer candidate reading through a long description of
how a package is built, would result in the candidates never applying.
 Now when I look back on my beginnings as a maintainer, I remember
that I looked around the website and quickly decided that the
documentation there is describing manual steps, which is clearly not
the way it's done, so I better avoid looking at it altogether.
Instead, I looked specifically for the source code repository.  It
wasn't obvious, because the words "source code" or "repository" are
nowhere to be found on the website.  If you look for
"site:www.opencsw.org repository -mantis", there only hits are from
the package pages, the subversion package being the first.  Once I
found the repository, I found the directory with the package that
interested me and tried to run it.  When It failed, I started pulling
apart the GAR code to understand what it does, and fixing any errors I
came across.  And I ended up with decent looking packages.  If I were
to base my package build attempts on the contents of www.opencsw.org,
I would give up building for OpenCSW and instead hack a bunch of
scripts to build the package only for myself.

I don't mean that I don't support documenting things.  It's good to
have a detailed description of the policy: what the policy is, and
what are the reasons behind it.  However, I oppose putting such
description forward as an operational document.

The new maintainers, who are most likely to make the most of mistakes,
should be presented with a relatively short description how to build a
package, leaving the checking to checkpkg.  It's hard enough to get
people to install Sun Studio and gar_devel, keeping the entry bar low
for people who want to try building a package for fun is an important
aspect of making the community grow.

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.

Maciej