[Mailman-Developers] Sibling list terminology (was Re: Mailman 2.1.10b4 Released)

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 14, 2008, at 7:30 AM, Ian Eiloart wrote:
>
>
> --On 13 March 2008 19:26:54 -0700 Mark Sapiro <mark at msapiro.net>  
> wrote:
>
>>
>> - - Added a new 'sibling list' feature to exclude members of  
>> another list
>> from receiving a post from this list if the other list is in the  
>> To: or
>> Cc: of the post or to include members of the other list if that  
>> list is
>> not in the To: or Cc: of the post (Patch ID 1347962).
>
> I don't understand this feature.... Hmm, Tokio Kikuchi asked about  
> the name
> in 2005. I'm sorry that I didn't comment earlier.
>
> <https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1347962&group_id=103 
> >
>
> Sibling is a *completely* misleading term for this feature, because  
> sibling
> relationships are necessarily symmetrical: if A is a sibling of B,  
> then B
> must be a sibling of A. This feature is necessarily anti- 
> symmetrical, more
> like "child" or "descendent". The term "sibling" will lead people to
> misconfigure their lists.
>
> <http://en.wikipedia.org/wiki/Symmetric_relation>
> <http://en.wikipedia.org/wiki/Antisymmetric_relation>
>
> Question: is the relationship also transitive? IE, if C is a child  
> of B,
> and B is a child of A, then will postings to A go to members of C?  
> If so,
> then the relationship should be called "descendent".
>
> <http://en.wikipedia.org/wiki/Transitive_relation>
>
> As far as inclusion is concerned, we then have a partially ordered  
> set of
> mailing lists under this relationship. If the code handles the  
> (presumably
> erroneous case) where a list is marked as a "sibling" of itself  
> properly
> (ie, the listing should be ignored).
>
> <http://en.wikipedia.org/wiki/Partial_order>

I didn't see any follow up on this, but perhaps I missed it while I  
was at Pycon.

Tokio can correct me, but I do not believe this feature is  
transitive.  There is a strictly one-level inclusion or exclusion of  
regular delivery addresses.

I see what you're saying about the term "sibling" lists being  
misleading.  But what's a good term?  I can't think of anything that  
encompasses both the inclusion and exclusion lists.  "Related" is  
about as close as I could come, but that's pretty uninformative.  It  
also might be too late to change for 2.1.10, especially if the u/i  
strings have already been translated.  Ultimately, it's Mark's  
decision, and changing it would be predicated on finding a good  
alternative.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfrDBoACgkQ2YZpQepbvXHm1QCbBE8LCvrIqcidwogr//L5zz9H
bSYAn2vgW62BRAktJ+IEf4VVPY1vpdNA
=/j/C
-----END PGP SIGNATURE-----