Mailing List Archive

On Wed, 23 Nov 2005 03:39:08 -0700
Duncan <1i5t5.duncan@cox.net> wrote:

> Here's the proposal again. If there's an issue with it, shoot it
> down, but from here, it certainly seems to fit the bill. Again,
> I'd /love/ to say I was the one that came up with it, but I wasn't.
> =8^)
>
> * give [AH]Ts a <name>.tester@gentoo.org address.
>
> - It's not a subdomain, so the existing infrastructure should have no
> problems with it.
>
> - testername.tester@gentoo.org remains distinctive enough it should
> alleviate any doubts or confusion over status.
>
> - the biggest possible objection I can see is that the root,
> tester@gentoo.org, is already in use. Thus, in particular, I'd like
> to see his reaction to this proposal. We could, of course, take the
> same idea and change the root, if necessary. My previous suggestion,
> intern, would work, or assistant, or something else. Tester is of
> course short and concise, but intern or assistant would be more
> generic, allowing the possiblity of other non-tester additions, in
> the future, with the same root.

Has the same problem as a subdomain as it creates two "classes" of
devs. So it would solve the potential technical problems, but we still
have the semantic issues.

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

On 11/23/05, Duncan <1i5t5.duncan@cox.net> wrote:
> Marius Mauch posted <20051123154049.6b5af84c@sven.genone.homeip.net>,
> excerpted below, on Wed, 23 Nov 2005 15:40:49 +0100:
>
> > On Wed, 23 Nov 2005 03:39:08 -0700
> > Duncan <1i5t5.duncan@cox.net> wrote:
> >
> >> Here's the proposal again. If there's an issue with it, shoot it down,
> >> but from here, it certainly seems to fit the bill. Again, I'd /love/ to
> >> say I was the one that came up with it, but I wasn't.
> >> =8^)
> >>
> >> * give [AH]Ts a <name>.tester@gentoo.org address.
> >>
> >> - It's not a subdomain, so the existing infrastructure should have no
> >> problems with it.
> >>
> >> - testername.tester@gentoo.org remains distinctive enough it should
> >> alleviate any doubts or confusion over status.
> >>
> > Has the same problem as a subdomain as it creates two "classes" of devs.
> > So it would solve the potential technical problems, but we still have the
> > semantic issues.
>
> Viewpoint seen, and thanks for posting it. However, the proposed solution
> still appears from here to fit the bill, because...
>
> - The folks to whom it will apply are /not/ full devs, as they haven't
> gone thru the dev process, so it's not creating two classes of devs, but
> rather creating a distinction between devs and this not-dev class.

Can we get all current developers renamed to nick.developer then? just
to alleiviate any confusion someone may have...

[snip a buttload or two]

--
gentoo-dev@gentoo.org mailing list

23.11.2005, 20:07:15, Dan Meltzer wrote:


> Can we get all current developers renamed to nick.developer then? just
> to alleiviate any confusion someone may have...

> [snip a buttload or two]

NO (I sincerely hope at least), and please let's finally stop messing w/ email
addresses causing further confusion and administrative overhead for no good
reason. :=(

*sigh*


--

jakub

forgot my sarcasm tags :)

Get the idea though?

On 11/23/05, Jakub Moc <jakub@gentoo.org> wrote:
>
> 23.11.2005, 20:07:15, Dan Meltzer wrote:
>
>
> > Can we get all current developers renamed to nick.developer then? just
> > to alleiviate any confusion someone may have...
>
> > [snip a buttload or two]
>
> NO (I sincerely hope at least), and please let's finally stop messing w/ email
> addresses causing further confusion and administrative overhead for no good
> reason. :=(
>
> *sigh*
>
>
> --
>
> jakub
>
>
>

--
gentoo-dev@gentoo.org mailing list

On Wed, Nov 23, 2005 at 11:47:18AM -0700 or thereabouts, Duncan wrote:
> As proposed, that recognizably distinct address was a subdomain. However,
> infra has objected to that as unworkable. However, the wording of the
> GLEP makes it clear that the subdomain was a proposal and that the details
> were to be worked out. What this "possible solution" does is provide a
> way for that to happen -- something infra shouldn't have issues with,
> while at the same time, implementing that aspect of the GLEP as adopted by
> the council.

The "possible solution" offers no technical or administrative advantages
over creating a sub-domain in the first place. The two solutions are
essentially equal.

> What I'm saying is that this is a solution consistent with the "situation
> on the ground" as we no have it. Sure, we can argue that the situation
> should be different, but this, from my viewpoint, is a pragmatic solution
> to a very tough and controversial problem, that the council has
> none-the-less expressed its view on, with said view approaching IMO about
> the best possible compromise between the opposing viewpoints.

This solution has the same yellow star stigma that the original proposal
does.

> I'm just trying to provide a way (thanks to the original suggestor) to
> "get some progress on the ground", instead of seeing it constantly
> debated, with no real conclusion or practical application of the debate in
> sight.

The only outstanding administrative issue is how these aliases are managed.
The same management issues exist regardless of whether we're talking about
foo.tester@gentoo.org or foo@tester.gentoo.org.

--kurt

Marius Mauch posted <20051123154049.6b5af84c@sven.genone.homeip.net>,
excerpted below, on Wed, 23 Nov 2005 15:40:49 +0100:

> On Wed, 23 Nov 2005 03:39:08 -0700
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>> Here's the proposal again. If there's an issue with it, shoot it down,
>> but from here, it certainly seems to fit the bill. Again, I'd /love/ to
>> say I was the one that came up with it, but I wasn't.
>> =8^)
>>
>> * give [AH]Ts a <name>.tester@gentoo.org address.
>>
>> - It's not a subdomain, so the existing infrastructure should have no
>> problems with it.
>>
>> - testername.tester@gentoo.org remains distinctive enough it should
>> alleviate any doubts or confusion over status.
>>
> Has the same problem as a subdomain as it creates two "classes" of devs.
> So it would solve the potential technical problems, but we still have the
> semantic issues.

Viewpoint seen, and thanks for posting it. However, the proposed solution
still appears from here to fit the bill, because...

- The folks to whom it will apply are /not/ full devs, as they haven't
gone thru the dev process, so it's not creating two classes of devs, but
rather creating a distinction between devs and this not-dev class.

- Lack of said distinction appears to have been one of the specific items
on the list the first time thru thru. The council said it had to be
added, so it was. The council then approved the change with the addition
made at their instruction.

Sure, we could go back and argue the wisdom of the original point made by
the council, but to this point, I haven't seen that seriously debated, nor
do I believe it should be, because either we accept that the council has
the authority to make those sorts of decisions or we don't, and if we
don't, what do we have a council for?

It would seem to me that there are two opposing viewpoints, one taking the
position that ATs should be practically treated as devs, no distinction,
the other taking the position that they are just users and the whole AT
position shouldn't exist. The council position seems to be a generally
reasonable compromise, that they are a class of user that should be
recognized as making a contribution and having responsibilities beyond
that of an ordinary user, but that they should remain distinct from full
devs, because they are NOT full devs. Part of that position is that they
get a gentoo mail address, but one recongizably distinct from that of a
gentoo dev.

As proposed, that recognizably distinct address was a subdomain. However,
infra has objected to that as unworkable. However, the wording of the
GLEP makes it clear that the subdomain was a proposal and that the details
were to be worked out. What this "possible solution" does is provide a
way for that to happen -- something infra shouldn't have issues with,
while at the same time, implementing that aspect of the GLEP as adopted by
the council.

What I'm saying is that this is a solution consistent with the "situation
on the ground" as we no have it. Sure, we can argue that the situation
should be different, but this, from my viewpoint, is a pragmatic solution
to a very tough and controversial problem, that the council has
none-the-less expressed its view on, with said view approaching IMO about
the best possible compromise between the opposing viewpoints.

I'm just trying to provide a way (thanks to the original suggestor) to
"get some progress on the ground", instead of seeing it constantly
debated, with no real conclusion or practical application of the debate in
sight.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Kurt Lieber posted <20051123222835.GI12982@mail.lieber.org>, excerpted
below, on Wed, 23 Nov 2005 22:28:35 +0000:

> This solution has the same yellow star stigma that the original proposal
> does.

Agreed, altho it seems that's the way the council wanted it...

> The only outstanding administrative issue is how these aliases are
> managed. The same management issues exist regardless of whether we're
> talking about foo.tester@gentoo.org or foo@tester.gentoo.org.

Then I missunderstood. The infra objections I'D read appeared (to me) to
be to the subdomain, as it wasn't an issue with the original GLEP.
However, I now see the original GLEP's proposal of addresses vs. the new
GLEP's proposal of aliases is a valid rendering of the objections as well,
and indeed, as you so patiently explain, this doesn't affect that aspect.
Being infra, that pretty absolutely quashes my previous understanding, and
with it, the proposed solution.

Thanks for making it clear to me. Shot down, indeed, but that's exactly
what I asked for! =8^) Too bad it wasn't that simple!

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list