[csw-maintainers] new mailing list?

[James Lee]

On 17/01/10, 21:28:45, William Bonnet <william at wbonnet.net> wrote regarding
Re: [csw-maintainers] new mailing list?:

> > Given that there is only a single registered 'nay' vote and that
> > procedural changes consist of _only_ sending the mail to a list
> > instead of an individual, I'd like to ask Ihsan to create the list,
> > with myself, Dago and Phil as members to start.
> >
> More generally, i would like to suggest that each of our process that
> needs email communication, should be using "functional" email addresses
> rather than "personal" (or "named") addresses. Whether the functional
> address is a mailing list or not.

This is a good idea and was called role based last time it was suggested
here.  Business email should be sent to a role but received by a person.
I also suggested that package maintenance represents a role and so
package email should go to ${package}@opencsw.org and be forwarded to a
person.  The key here is the person can change without changing the
email address.

Roles based addressing is not the same as having a mailing list behind
it.  This request seems like a classic example of wanting to see
something because you can't and not because once seen there is any net
benefit to logging every action.  There are some activities that do not
need to be logged in detail and broadcast, for example I had a poo this
morning, does anyone want to see my log?

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.

There may be some messages associated with refusal.  If broadcast and
recorded by a mailing list there is the potential for public humiliation.
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.



James.