The mailing list for listmasters using Sympa

[Olivier Salaün - CRU <address@concealed>]

Hi Jeff,

Jeff Abbott wrote: On Nov 4, 2005, at 9:24 AM, Olivier Salaün - CRU wrote:

Yes a family list can be removed just like a "normal" list.
A  single list can also be added to a family with 'sympa.pl -- add_list', as described here  : http://www.sympa.org/doc/html/ node18.html#SECTION001825000000000000000

But can this take an existing list and add it into a family, or just  add a new list to the family?
No you can't take an existing list and add it to a family because the input to create a family list is :

1. a family template (config.tt2)
2. a set of XML data
   

Note that (1) and (2) are tied together because the template make use of variables that might be specific to the family. Moving a list from one family requires that you instanciate the new family template with the set of data of the list. But since they might use a different set of variables, you might be in trouble...

[...]

Is  it possible to take a family-based list and move it to  another  family,

We did not take this as a desired feature in the families design.  What would be the goal of this operation ?

I believe an example would be the best way to illustrate this.  Let's  say we've got a pair of families, "default" and "archived."  A user  has a list in the "default" family, which has the web archive  disabled.  They realize they want the archive and request that it be  turned on, so I would want to move it from the "default" family to  the "archived" family, which has archiving enabled and set to some  reasonable values so as to prevent a list from taking up too much  space.  Can this be done by simply changing the list's family parameter?
This is not way families should be used.

The reason why we implemented this feature in Sympa was to allow institutions such as universities to create a bundle of lists automatically. Apart from the fact that they all had to write the same homemade script, they could not update this set of mailing lists during the year, otherwise they would loose all list customizations.

If we wanted to move a list from one family to another and respect what was the family philosophy, then we should :

1. instanciate the list XML data with the new family template
2. raise an error if some input data are missing to instanciate the list
   
3. only accept list parameters that are allowed within the new family
   

I suppose what's more important would be asking if this is something  that we should be doing with families, or should we just let users  change most settings on their own and not worry about it, using  edit_list.conf to enforce those that we don't want them to be able to  change?

You can do that, just removing the list's 'family' parameter.

Excellent.  That's simple enough.

I guess my primary concern is that I don't trust our users enough to  not mess things up for everyone else.  We've got a lot of non- technical people here who wouldn't think things through before making  a change to a list that might impact other users.  Maybe I'm  overreacting or the hypothetical situations I can come up with in my  mind simply won't happen in the real world.
If you are dealng with family lists, then you can control what parameter can be edited and what values it can take.
If you're not in the family world, then edit-list.conf still provide you a way to define what parameter can be edited by owners. For example, the default edit-list.conf we distribute does not allow list "basic" owners to change the 'send' parameter (that defines who is autorized to submit a message to the list) because it is a very sensible parameter and only the listmaster or the privileged owner can change it.
What do other people on the list use list families for, or do other  people in environments similar to ours not use families at all?

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature