1 |
Top posting, since trying to make a point here in relation to |
2 |
everything that follows from your email. |
3 |
|
4 |
define exactly how one proves themself, and in what context. |
5 |
|
6 |
It's the arguement against (essentially) having AT's on the same level |
7 |
as ebuild devs, so it best be defined. |
8 |
|
9 |
|
10 |
On Tue, Sep 13, 2005 at 04:14:34AM +0100, Ciaran McCreesh wrote: |
11 |
> On Mon, 12 Sep 2005 23:01:20 -0400 Alec Warner <warnera6@×××××××.edu> |
12 |
> wrote: |
13 |
> | I'm not confusing anything here. Arch Devs ( ala members of arch |
14 |
> | teams ) and Arch testers should be equal in terms of developer |
15 |
> | status. |
16 |
> |
17 |
> Why? Arch testers *aren't* full developers. They may become them, but |
18 |
> they haven't yet demonstrated that they're capable of being a full |
19 |
> developer. |
20 |
> |
21 |
> | voting previleges |
22 |
> |
23 |
> Again, why? They have not yet demonstrated their understanding of |
24 |
> complex technical issues. Voting should be restricted to people who |
25 |
> know what they're doing. Arch testers have not yet proven themselves. |
26 |
> |
27 |
> | > Assuming by "arch dev" you mean "arch tester", then: |
28 |
> | > |
29 |
> | > Experience, commitment and (at least in theory) recruitment |
30 |
> | > standards. |
31 |
> | |
32 |
> | Commitment first: |
33 |
> | IMNSHO, it is rude to assume that an Arch Tester is less commited to |
34 |
> | their work than an Arch Team member. All developers should be doing |
35 |
> | their part and should hopefully ( we don't live in an ideal world here |
36 |
> | after all ) be commited to doing their work well. A lack of |
37 |
> | commitment that results in shoddy work should get them removed from |
38 |
> | any developer role, Arch Team member or otherwise. |
39 |
> |
40 |
> An arch tester has not committed himself to the project for the same |
41 |
> length of time as a full developer. |
42 |
> |
43 |
> | Being a Gentoo developer isn't ( or I should say, shouldn't be ) all |
44 |
> | about what happens in CVS. There are many people who support other |
45 |
> | portions of gentoo forums/bugs/devrel/testing/user |
46 |
> | relations/gentooexperimental.org/etc and some sort of stupid elitism |
47 |
> | about being a "better dev" or a dev that has "better skillz" because |
48 |
> | said dev has commit access is simply stupid. Devs with commit access |
49 |
> | may be skilled in the workings of the tree ( and there are certainly |
50 |
> | devs with commit access that do not possess such a skillset ), but |
51 |
> | that should be why they have commit access, because they possess the |
52 |
> | skills to manage the tree. |
53 |
> |
54 |
> Uhm... Different people have different skill levels. Some of this is |
55 |
> down to natural ability, some of it is down to experience. Arch testers |
56 |
> have not yet proven themselves. Full developers have (at least in |
57 |
> theory...). |
58 |
> |
59 |
> | Personally I would rather see people's CVS commit access by |
60 |
> | herd/package/section than just "generic tree access". Commiting |
61 |
> | something outside your Role becomes then contacting someone who knows |
62 |
> | what they are doing and who can look over your work (good!). The bad |
63 |
> | part being when no one is around who has commit access. A resolution |
64 |
> | for this situation would need to be required. Expections would need |
65 |
> | to occur as well ( tree-wide commits, and other things that happen |
66 |
> | from time to time ). However I'd like to see more input on things |
67 |
> | like this ( along with say, council approval? :) ). |
68 |
> |
69 |
> Take a look at the branches proposal that's been floating around. It's |
70 |
> basically what you suggested with fewer holes and a more realistic view |
71 |
> of how development gets done. |
72 |
> |
73 |
> -- |
74 |
> Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) |
75 |
> Mail : ciaranm at gentoo.org |
76 |
> Web : http://dev.gentoo.org/~ciaranm |
77 |
> |
78 |
|
79 |
|
80 |
~harring |