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

[Mark Sapiro]

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

Barry Warsaw wrote:
| 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.


There wasn't any. At one point, I was going to reply, but I got distracted.


| 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.


That is correct.


| 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.


Related (or Relative) was the alternative idea that occurred to me as
well, but as you say, it isn't very informative.

| 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.

The actual word "sibling" appears in a few places. It is in the title of
the subsection for configuring regular_(in|ex)clude_lists, and is
mentioned in the detailed help for these settings in the phrase "site
administrator may prohibit cross domain siblings". It is also in the
configuration variable ALLOW_CROSS_DOMAIN_SIBLING.

I would be reluctant to change this for 2.1.10 because the existing
strings have been translated in a few updates, and I have been actively
trying to keep from making any further changes to i18n strings.

As far as whether the 'sibling' relationship is symmetric or
antisymmetric, this is a question that can only be answered if the
definition of the relationship is precise enough. There are at least two
possible definitions that make sense to me.

1) List A is a sibling of list B iff list A appears in one of list B's
regular_(in|ex)clude_lists attributes.

2) List A is a sibling of List B iff list A appears in one of list B's
regular_(in|ex)clude_lists attributes or list B appears in one of list
A's regular_(in|ex)clude_lists attributes.

Under definition 1), the 'sibling' relationship is neither symmetric nor
antisymmetric. Under definition 2), the 'sibling' relationship is
symmetric and not antisymmetric.

As far as a list being in it's own regular_(in|ex)clude_lists, as a
result of Ian's original post, I changed the GUI to not allow it and
changed the handler to ignore it, but log it.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFH6/7fVVuXXpU7hpMRAg3OAJ93X8ZrNEnRPTJlJSVVSrjUACXdjQCgvHkS
JEQvKrmvbL2obz4ybyrX728=
=Fqg8
-----END PGP SIGNATURE-----