Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Alec Warner]

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

Ciaran McCreesh wrote:
> On Mon, 12 Sep 2005 21:41:37 -0400 Alec Warner <warnera6@×××××××.edu>
> wrote:
> | And how is an "Arch Dev" different from say a member of devrel?
>
> Assuming by "arch dev" you mean "arch tester", then:
>
> Experience, commitment and (at least in theory) recruitment standards.
>
> Stop confusing arch devs (who have commit access) with arch testers
> (who do not have any formal powers other than being able to advise with
> more authority than regular users). Arch testers may (and hopefully
> will) become full arch developers later.
>

The whole point of this GLEP is to make Arch Testers official Gentoo
Staff.  Giving them E-mail addresses, giving them read only CVS access,
etc.  Geoman is saying why give them different status at all, and is not
saying their status is lower than a "normal dev".

>> You're somehow implying that being an AT is not as good as being a >dev.
>
>Wrong.
>
>> My understanding is that this GLEP is supposed to make AT as good as
>> being a dev, but with a different role, one that doesn't need commit
>> access.
>My point exactly!  Why have another category?

I'm not confusing anything here.  Arch Devs ( ala members of arch teams
) and Arch testers should be equal in terms of developer status.  All
should have E-mail, voting previleges, etc.  One role does not
explicitely require CVS write access ( Arch Tester ) and one role does (
Arch Teams ).  Geoman is talking about new categories when in fact it is
really just a new developer role.  Just as devrel is a role, which has
certain access that accompanies it, so will an Arch Tester.
> Assuming by "arch dev" you mean "arch tester", then:
>
> Experience, commitment and (at least in theory) recruitment standards.

Commitment first:
IMNSHO, it is rude to assume that an Arch Tester is less commited to
their work than an Arch Team member.  All developers should be doing
their part and should hopefully ( we don't live in an ideal world here
after all ) be commited to doing their work well.  A lack of commitment
that results in shoddy work should get them removed from any developer
role, Arch Team member or otherwise.

Experience Second:
Arch Testers are generally less experienced in other areas of being a
gentoo developer, the same as if taking someone from say QA and telling
them they have to file perfect patches to Portage or Catalyst.  Those
patches are going to either be long in coming or generally not high
quality until the developer learns about what they are working on.  No
one expects an Arch Tester to just grab commit access and commit things
to the tree.

Being a Gentoo developer isn't ( or I should say, shouldn't be ) all
about what happens in CVS.  There are many people who support other
portions of gentoo forums/bugs/devrel/testing/user
relations/gentooexperimental.org/etc and some sort of stupid elitism
about being a "better dev" or a dev that has "better skillz" because
said dev has commit access is simply stupid.  Devs with commit access
may be skilled in the workings of the tree ( and there are certainly
devs with commit access that do not possess such a skillset ), but that
should be why they have commit access, because they possess the skills
to manage the tree.

Recruiment Standards ( Long ):  Recruitment standards are generally set
on a Role by Role basis.  This is a problem only in that the requirement
to become a developer could be very low in one Role and allow the
developer to "hop" to another Role where they wreak havoc because they
lack experience in their new Role.  A contrived example would be a docs
dev who writes say, Klingon documentation, decides to manage a few
packages who have no maintainer.  He took the ebuild quiz 6 months ago
but generally doesn't know what he is doing.  Then he commits a bunch of
crappy ebuilds to the tree for his packages and generally causes trouble
with his work.

This type of deal is usually solved at a decent level by people in their
Role keeping track of developers who do work.  However sometimes this is
not done ( I think this is quite rare actually ) or in a more often
case, there is no one watching.  The Klingon Docs dev picks up some dead
packages, commits the bad changes, and no one is the wiser until things
break.  Perhaps this too could be solved by a peer review system of
changes, making it harder to commit an ebuild.  Maybe commiting doesn't
commit directly to CVS but instead commits to a peer-review section
where it must be reviewed and approved by a second developer in the
herd.  Of course that would never happen because no one has the time to
review all of the ebuilds.

Personally I would rather see people's CVS commit access by
herd/package/section than just "generic tree access".  Commiting
something outside your Role becomes then contacting someone who knows
what they are doing and who can look over your work (good!).  The bad
part being when no one is around who has commit access.  A resolution
for this situation would need to be required.  Expections would need to
occur as well ( tree-wide commits, and other things that happen from
time to time ).  However I'd like to see more input on things like this
( along with say, council approval? :) ).

Sorry about the long-winded recruitment bit ;)

- -Alec Warner (antarus)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQyZBAGzglR5RwbyYAQLJgw/+LUIpnMWlk9pI19p7nFtDZ+/IC1CODinA
byJY+3i1YMzt12GO8FK5WAqXkEYmOkwvcYkw8wryCtGgwfkkPfdoE44yUMV/ACKU
KOakWke3Ew3AWclExLo+4WZ0A6C4NAHQMA6YA90SWNg43R7Q5zBrQMIcz2gD5l14
CwYRR2xSj++TreO+4P74+lciWhf/TF9+ZUlVzMyMTCScGnNccfUbbFVrbpxRE/vV
htVkjbcE4vTud/Z3MfIqySB1ByaqHg3NlwnNEjg+FivS1J8HBlmhDGBAwmjheNtf
Jcn+n0NrUepShC/MX/ObXVz5jRnKuqHnBhS3fGy7OZg3ujS6cGEQLvzF4RKCagk/
f1RxLLBwHZlZqU1w4rvalYpjGXb8RicGABf4FfCII/IQqRBwdA2dXR9DfEPnyW+E
uIV/i4ZM8NSIYLN+xtpZdU/z2/BxWf2i/MSjBTYlooYYAgdO9wBFo16tUV64pkmq
Ttzr3cjgFGTHfrCu+a9r+1OYwrykgAnpim/H5W+BE8PULPBSAhtlLnJPoBFRSx+A
hCorOSJQadBOW4XFN9IsKPHnQvffm3PLe0weidL2xHoLusZVpnO/wm2kXrrcTyQ8
+FMV6hw6MorvqvGgBUgmXjeljWggWtOxifXIWDSe7Dv4g+V4tdAcgw3++ZtN4sXs
898BGeefDqU=
=Ae5f
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list