1 |
Marius Mauch posted <20051123154049.6b5af84c@××××××××××××××××××.net>, |
2 |
excerpted below, on Wed, 23 Nov 2005 15:40:49 +0100: |
3 |
|
4 |
> On Wed, 23 Nov 2005 03:39:08 -0700 |
5 |
> Duncan <1i5t5.duncan@×××.net> wrote: |
6 |
> |
7 |
>> Here's the proposal again. If there's an issue with it, shoot it down, |
8 |
>> but from here, it certainly seems to fit the bill. Again, I'd /love/ to |
9 |
>> say I was the one that came up with it, but I wasn't. |
10 |
>> =8^) |
11 |
>> |
12 |
>> * give [AH]Ts a <name>.tester@g.o address. |
13 |
>> |
14 |
>> - It's not a subdomain, so the existing infrastructure should have no |
15 |
>> problems with it. |
16 |
>> |
17 |
>> - testername.tester@g.o remains distinctive enough it should |
18 |
>> alleviate any doubts or confusion over status. |
19 |
>> |
20 |
> Has the same problem as a subdomain as it creates two "classes" of devs. |
21 |
> So it would solve the potential technical problems, but we still have the |
22 |
> semantic issues. |
23 |
|
24 |
Viewpoint seen, and thanks for posting it. However, the proposed solution |
25 |
still appears from here to fit the bill, because... |
26 |
|
27 |
- The folks to whom it will apply are /not/ full devs, as they haven't |
28 |
gone thru the dev process, so it's not creating two classes of devs, but |
29 |
rather creating a distinction between devs and this not-dev class. |
30 |
|
31 |
- Lack of said distinction appears to have been one of the specific items |
32 |
on the list the first time thru thru. The council said it had to be |
33 |
added, so it was. The council then approved the change with the addition |
34 |
made at their instruction. |
35 |
|
36 |
Sure, we could go back and argue the wisdom of the original point made by |
37 |
the council, but to this point, I haven't seen that seriously debated, nor |
38 |
do I believe it should be, because either we accept that the council has |
39 |
the authority to make those sorts of decisions or we don't, and if we |
40 |
don't, what do we have a council for? |
41 |
|
42 |
It would seem to me that there are two opposing viewpoints, one taking the |
43 |
position that ATs should be practically treated as devs, no distinction, |
44 |
the other taking the position that they are just users and the whole AT |
45 |
position shouldn't exist. The council position seems to be a generally |
46 |
reasonable compromise, that they are a class of user that should be |
47 |
recognized as making a contribution and having responsibilities beyond |
48 |
that of an ordinary user, but that they should remain distinct from full |
49 |
devs, because they are NOT full devs. Part of that position is that they |
50 |
get a gentoo mail address, but one recongizably distinct from that of a |
51 |
gentoo dev. |
52 |
|
53 |
As proposed, that recognizably distinct address was a subdomain. However, |
54 |
infra has objected to that as unworkable. However, the wording of the |
55 |
GLEP makes it clear that the subdomain was a proposal and that the details |
56 |
were to be worked out. What this "possible solution" does is provide a |
57 |
way for that to happen -- something infra shouldn't have issues with, |
58 |
while at the same time, implementing that aspect of the GLEP as adopted by |
59 |
the council. |
60 |
|
61 |
What I'm saying is that this is a solution consistent with the "situation |
62 |
on the ground" as we no have it. Sure, we can argue that the situation |
63 |
should be different, but this, from my viewpoint, is a pragmatic solution |
64 |
to a very tough and controversial problem, that the council has |
65 |
none-the-less expressed its view on, with said view approaching IMO about |
66 |
the best possible compromise between the opposing viewpoints. |
67 |
|
68 |
I'm just trying to provide a way (thanks to the original suggestor) to |
69 |
"get some progress on the ground", instead of seeing it constantly |
70 |
debated, with no real conclusion or practical application of the debate in |
71 |
sight. |
72 |
|
73 |
-- |
74 |
Duncan - List replies preferred. No HTML msgs. |
75 |
"Every nonfree program has a lord, a master -- |
76 |
and if you use the program, he is your master." Richard Stallman in |
77 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
78 |
|
79 |
|
80 |
-- |
81 |
gentoo-dev@g.o mailing list |