1 |
On Mon, 2005-09-12 at 19:53 -0400, Stephen P. Becker wrote: |
2 |
> >>Let me clarify here. I'm not concerned about ATs having more privileges |
3 |
> >>at all. I just want to know why if we're making them full developers |
4 |
> >>for all intents and purposes, we don't go the extra step and get them |
5 |
> >>commit access after a probationary period? It seems like this is |
6 |
> >>supposed to be the end goal anyway. Basically, I feel like this GLEP |
7 |
> >>goes outside the bounds of what I think of when somebody mentions the |
8 |
> >>arch testers. Maybe it's just me though. |
9 |
> >> |
10 |
> >>-Steve |
11 |
> > |
12 |
> > |
13 |
> > For once agreeing with Ciaran, the less people who aren't seasoned |
14 |
> > developers with commit access the better? Some don't want commit |
15 |
> > access, most of them really don't need it. Those that want it can ask |
16 |
> > for it and take any requisite quizzes. |
17 |
> |
18 |
> You also have misunderstood my point. I've always been under the |
19 |
> impression that ATs are regarded highly enough that they could easily |
20 |
> become members of the dev team. With that in mind, *if* we are going to |
21 |
> give them nearly every privilege an arch dev has anyway, why not go one |
22 |
> step further and just make them an official arch dev and avoid |
23 |
> unnecessary bloating of categories with respect to Gentoo dev-team |
24 |
> membership? They don't even need commit access if they don't want it. |
25 |
> We currently have developers without tree access already in any case. |
26 |
> Should we reclassify those folks as well? |
27 |
|
28 |
You're somehow implying that being an AT is not as good as being a dev. |
29 |
My understanding is that this GLEP is supposed to make AT as good as |
30 |
being a dev, but with a different role, one that doesn't need commit |
31 |
access. If the people involved decide they want to become committing |
32 |
devs, it also make it easier to make that transition. If they don't |
33 |
want to commit, they can stay as an AT. |
34 |
|
35 |
> Besides, if you want to get technical, our entire userbase are arch |
36 |
> testers to some extent. They run Gentoo, report bugs, unmask packages |
37 |
> locally, submit keywording requests to bugzilla, etc. The good users |
38 |
> make Gentoo a good distribution by providing feedback on bugzilla. The |
39 |
> very best of these folks are typically tapped for membership in arch teams. |
40 |
|
41 |
I agree. What the AT program has done for amd64, tho, is give us a base |
42 |
of users that have known skills (they were recruited and passed the |
43 |
ebuild quiz) and have a known process they follow for testing and |
44 |
marking bugs, so that the devs have a much easier time staying on top of |
45 |
keywording issues. We've basically said that we trust the ATs to know |
46 |
how to test a package, and we'll take their word for it that it works. |
47 |
It's been very useful for us, and we think it will be useful for others. |
48 |
|
49 |
Daniel |
50 |
(former AT) |
51 |
|
52 |
-- |
53 |
gentoo-dev@g.o mailing list |