[Mailman-Developers] Sibling list terminology (was Re: Mailman 2.1.10b4 Released)
barry at list.org
Thu Mar 27 03:53:12 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
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>
>> - - 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.
> Sibling is a *completely* misleading term for this feature, because
> 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.
> 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".
> As far as inclusion is concerned, we then have a partially ordered
> set of
> mailing lists under this relationship. If the code handles the
> erroneous case) where a list is marked as a "sibling" of itself
> (ie, the listing should be ignored).
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
-----END PGP SIGNATURE-----
More information about the Mailman-Developers