| 1 |
I've picked the top mail in this thread to response to a single issue, |
| 2 |
because I think it's important. Dilfridge was in #gentoo-infra earlier |
| 3 |
this week, trying to figure out projects->alias generation, and we had |
| 4 |
a productive discussion of some the fundamental issues behind that goal. |
| 5 |
|
| 6 |
This email is a result of that discussion. |
| 7 |
|
| 8 |
On Wed, Sep 30, 2015 at 08:15:37PM +0200, Michał Górny wrote: |
| 9 |
> 1c. We may also automatically add members to mail aliases from |
| 10 |
> herds.xml if someone really wants that. But again, not a priority. |
| 11 |
|
| 12 |
A lot of this discussion seems to conflate project membership with being |
| 13 |
on a mail alias, and this is problematic in various ways. |
| 14 |
|
| 15 |
0. Some projects have MORE than one alias. |
| 16 |
|
| 17 |
1. While project membership MUST be public, it's entirely possible that |
| 18 |
some or all of the alias members are private: |
| 19 |
1.1. Infra & Security aliases: Some of the aliases themselves might be |
| 20 |
secret, used to filter some mail. The list of addresses on the alias is |
| 21 |
also private. |
| 22 |
1.1.1. "private alias" => members of the alias are hidden, but the alias name is published |
| 23 |
1.1.2. "secret alias" => the alias name is not published |
| 24 |
1.2. Some contributors to projects LIKE their privacy and/or have |
| 25 |
specific addresses for the alias. This set includes upstream devs that |
| 26 |
care about Gentoo bugs for their app. |
| 27 |
|
| 28 |
2. Just because a developer is a member of a project, does not always |
| 29 |
they want ALL the mail on a given alias. Some aliases, esp the older |
| 30 |
ones or more central ones are firehoses of both real bug mail and |
| 31 |
spam. |
| 32 |
|
| 33 |
The combination of these points has a few implications: |
| 34 |
|
| 35 |
A. Developers need to be able to opt-out of an alias while retaining |
| 36 |
project membership. |
| 37 |
A.1. Should this fact be visible? |
| 38 |
|
| 39 |
B. Non-developer members of a project need to addable to an alias by a |
| 40 |
developer |
| 41 |
B.1. While preserving the privacy of that contributor entirely, if they |
| 42 |
don't want to show up on a listing of members) |
| 43 |
B.2. While preserving the privacy of the contributor's email address, if |
| 44 |
they don't want their email address published. |
| 45 |
B.2.1. Additional implication is that the email addresses CANNOT be in a |
| 46 |
public repository at all! |
| 47 |
B.3. This scares some developers, not known that a non-developer is on a |
| 48 |
mail alias. |
| 49 |
|
| 50 |
From this, I have a rough plot of a data model that tries to take it |
| 51 |
into account. It doesn't cover where to store it, other than it needs to |
| 52 |
be private. |
| 53 |
|
| 54 |
= Projects have members |
| 55 |
== members fall into two groups: developers, contributors |
| 56 |
== members can be public or private, this controls if they are shown on the wiki etc. |
| 57 |
== developers are public members by default |
| 58 |
== contributors are private members by default |
| 59 |
= Projects have mail aliases |
| 60 |
== members opt into project mail aliases. |
| 61 |
== Public project members NOT in a mail alias are visibly flagged. |
| 62 |
== Private project members IN a mail alias are visibly flagged (how to |
| 63 |
do this without exposing them too much?) |
| 64 |
|
| 65 |
I think part of the solution will lie in separating the identity of a |
| 66 |
contributor vs their email address: Allow viewing of who is on an alias |
| 67 |
without exposing the actual email address. |
| 68 |
|
| 69 |
"John X. (upstream author)" in a alias listing is MUCH more useful than |
| 70 |
a random email address. |
| 71 |
|
| 72 |
-- |
| 73 |
Robin Hugh Johnson |
| 74 |
Gentoo Linux: Developer, Infrastructure Lead |
| 75 |
E-Mail : robbat2@g.o |
| 76 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
Archives