-----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@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.
List A is a sibling of list B iff list A appears in one of list B's regular_(in|ex)clude_lists attributes.
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@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-----