From: Brian Harring <ferringb@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Date: Tue, 13 Sep 2005 00:39:31 -0500 [thread overview]
Message-ID: <20050913053931.GC7156@nightcrawler> (raw)
In-Reply-To: <20050913041434.6d458342@snowdrop.home>
[-- Attachment #1: Type: text/plain, Size: 5810 bytes --]
With the 'proven' definition being repeated contributions, and
explicit in the previous email the view AT's are lesser, but can move
'up' to the level of an ebuild dev, back to this email...
On Tue, Sep 13, 2005 at 04:14:34AM +0100, Ciaran McCreesh wrote:
> On Mon, 12 Sep 2005 23:01:20 -0400 Alec Warner <warnera6@egr.msu.edu>
> wrote:
> | I'm not confusing anything here. Arch Devs ( ala members of arch
> | teams ) and Arch testers should be equal in terms of developer
> | status.
>
> Why? Arch testers *aren't* full developers. They may become them, but
> they haven't yet demonstrated that they're capable of being a full
> developer.
Arch devs != ebuild devs != ATs
They're different roles.
Stop intermixing them, unless you're going to start throwing portage devs,
doc devs, infra, and devrel in.
There _is_ a common subset to portage devs, arch devs, ebuild devs, and ATs,
but that does not mean they're equal in requirements and roles.
Each has a role, don't blur the AT definition into ebuild devs unless
you've after eliminating AT positions (something I doubt going by your
previous QA threads); if you're after that, state so please.
> | voting previleges
>
> Again, why? They have not yet demonstrated their understanding of
> complex technical issues. Voting should be restricted to people who
> know what they're doing. Arch testers have not yet proven themselves.
Have doc devs demonstrated their understanding of complex technical
issues? Portage devs? Infra?
Your metric frankly is rather vague. Come up with one applicable to
AT's rather then vague terms impying AT's are not of the 'elite'
ebuild dev standard please.
Additionally, Note that those proposing the glep utilize AT's in their
arch; they may have a different view of role/ability of the AT's then
you do, and of their abilities.
IOW, nail down your metric, then apply it to the existing AT's (since
they are what we have to work with), and then re-raise your views that
they "don't know what they're doing".
Back to the "complex technical issues", point I'm getting at is that
the problem domain of both differ, even if they may have a common
subset.
> | > 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.
>
> An arch tester has not committed himself to the project for the same
> length of time as a full developer.
This is mild BS, since it's a common issue to all classes of gentoo
volunteers. Further, stats provided (as were requested) I'd posit are
actually better then ebuild dev stats, although worth noting the
sampling period differs.
> | 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.
>
> Uhm... Different people have different skill levels. Some of this is
> down to natural ability, some of it is down to experience. Arch testers
> have not yet proven themselves. Full developers have (at least in
> theory...).
Not much for the natural ability bit/elitist stuff; the question is
what they've demonstrated, the work done. Doesn't matter if it
takes a person 20 hours, or 1, it's the end product people see,
and what ultimately matters (as you've pointed out in re: to QA).
Beyond that, I don't agreew with the "Arch testers haven't proven themselves".
They wouldn't be marked as AT's by the arch if they hadn't demonstrated
some form of worth, just the same as ebuild devs aren't recruited if
they haven't shown some form of worth (this includes ability to stick
around for more then a month). Screwups happen, but the stats offered
are a pretty good indication they've got that angle addressed imo.
The only bit I'd actually disagree with on the glep is the 2 weeks
period for conversion of an AT to an ebuild devs; the two roles (imo)
are seperate, those handling ebuild devs should set the requirements
themselves, just the same as those handling AT devs should set the
requirements they perceive as needed.
My 2 cents? They're doing work for gentoo. They may, or may not want
to become ebuild devs (that being they're choice, and decided by those
handling ebuild devs). Doesn't really matter, not everyone wants to
be a pkg maintainer.
Treating contributors as second class citizens (in terms of cvs ro
access and email) is a really great way to piss on people who are
doing a good chunk of work for gentoo.
They *should* be provided better means of doing their work, and should
be thrown the email addie as recognition for their contributions once
they've met the common requirements of all gentoo personel (sticking
around, contributing, etc).
~harring
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-09-13 5:41 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-12 19:39 [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff Simon Stelling
2005-09-12 19:50 ` Ciaran McCreesh
2005-09-12 21:10 ` Martin Schlemmer
2005-09-12 21:13 ` Olivier Crete
2005-09-12 21:17 ` Homer Parker
2005-09-12 19:56 ` Stephen P. Becker
2005-09-12 20:18 ` Simon Stelling
2005-09-12 20:08 ` Martin Schlemmer
2005-09-12 20:13 ` Donnie Berkholz
2005-09-12 20:30 ` Stephen P. Becker
2005-09-12 20:47 ` Homer Parker
2005-09-12 20:57 ` Stephen P. Becker
2005-09-12 21:20 ` Homer Parker
2005-09-12 21:02 ` Simon Stelling
2005-09-12 21:21 ` Homer Parker
2005-09-12 21:46 ` Joseph Jezak
2005-09-12 22:12 ` Homer Parker
2005-09-12 20:36 ` Simon Stelling
2005-09-12 20:45 ` Homer Parker
2005-09-12 21:08 ` Diego 'Flameeyes' Pettenò
2005-09-12 20:59 ` Wernfried Haas
2005-09-12 23:05 ` Daniel Drake
2005-09-13 0:14 ` Homer Parker
2005-09-13 0:15 ` Daniel Gryniewicz
2005-09-13 7:04 ` Chris White
2005-09-12 22:47 ` Stephen P. Becker
2005-09-12 23:16 ` Martin Schlemmer
2005-09-12 23:34 ` Alec Warner
2005-09-12 23:53 ` Stephen P. Becker
2005-09-13 0:13 ` Daniel Gryniewicz
2005-09-13 0:26 ` Stephen P. Becker
2005-09-13 0:47 ` Nathan L. Adams
2005-09-13 1:41 ` Alec Warner
2005-09-13 1:50 ` Ciaran McCreesh
2005-09-13 3:01 ` Alec Warner
2005-09-13 3:14 ` Ciaran McCreesh
2005-09-13 3:51 ` Brian Harring
2005-09-13 4:04 ` Ciaran McCreesh
2005-09-13 11:26 ` Simon Stelling
2005-09-13 12:00 ` Luca Barbato
2005-09-13 13:08 ` Mike Doty
2005-09-13 13:49 ` Wernfried Haas
2005-09-13 4:27 ` Homer Parker
2005-09-13 11:22 ` Simon Stelling
2005-09-16 15:38 ` Lares Moreau
2005-09-13 5:39 ` Brian Harring [this message]
2005-09-13 16:14 ` Ciaran McCreesh
2005-09-13 11:21 ` Simon Stelling
2005-09-13 16:13 ` Ciaran McCreesh
2005-09-13 0:11 ` Homer Parker
2005-09-13 0:10 ` Homer Parker
2005-09-18 6:26 ` [gentoo-dev] " R Hill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050913053931.GC7156@nightcrawler \
--to=ferringb@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox