1 |
Although I like the arch testers (ATs) idea pretty much, I have some |
2 |
questions: |
3 |
|
4 |
- Why have the 'low hanging fruit' bugs from before 2005 not been |
5 |
resolved till I run through them a few weeks ago?. Most of them were |
6 |
small and had no USE flags. I expect the devs that had no time to do |
7 |
this in the past won't have time to do it when an AT has run over it. |
8 |
In the end, the dev is responsible for the commit, not the AT, hence I |
9 |
would not be surprised if the dev does a (non USE flag extensive) |
10 |
compilation on his own machine before committing to CVS. A trust |
11 |
relationship between dev and AT is neccessary too and needs to be |
12 |
built. |
13 |
- Maybe AT's should be 'assigned' to one or two devs who are |
14 |
responsible for committing the AT's work. This is a natural mentor |
15 |
relationship as well as QA wise, it is obvious who is going to punish |
16 |
you if your work is not correct ;) |
17 |
- This proposal assumes ATs have time, which devs apparently have not. |
18 |
I agree that the AT work is simple, but boring. Though I still like |
19 |
to know why it hasn't been done in the past. |
20 |
- Assuming I'd have an AT or two assigned to me, I'd like to have the |
21 |
freedom to give them more flesh if they are hungry for it, i.e. dive |
22 |
into why something doesn't configure/build/compile/install and try to |
23 |
come up with a patch. Maybe this is dev dependant, but I think for an |
24 |
AT it would be nice to know there is a road upstairs: if they're good, |
25 |
and do what they do very well, it would be nice if I wouldn't have to |
26 |
commit their work. (in other words: promote such AT to a dev) On the |
27 |
other hand, you still need the AT work to be done. |
28 |
|
29 |
I think the draft is a good piece of work. I'm almost eager to have |
30 |
one, like a PhD who gets an MSc assigned to him. My experiences with |
31 |
some bug reporters who were also in IRC to fix bugs using direct |
32 |
feedback from them is very productive, however if I slam myself in the |
33 |
face and throw some cold water over my head I feel myself forced to look |
34 |
at the issue from a much more pessimistic point of view considering this |
35 |
team and the current 'productiveness'. |
36 |
|
37 |
Currently, we only discuss the way 'up', but maybe the way 'down' should |
38 |
be in the picture too. An AT should be considered to be 'active'. |
39 |
Where active means that such AT can do some useful work on a regular |
40 |
base. (Note: this implicitly requires devs to be at least as active as |
41 |
the AT.) If not, while there is work enough, such AT should be removed. |
42 |
Might sound obvious, but if there are no hard rules for it, noone will |
43 |
get removed. |
44 |
|
45 |
Ok, I better stop this lengthy email right here. Considering the |
46 |
statistics, it's way to long to be entirely read by most people anyway |
47 |
;) For those that skipped the middle part, a short recap: |
48 |
|
49 |
Yes, nice idea, but I think we should look at the problem from inside |
50 |
this very team first. I would consider the average participation level |
51 |
very unhealthy. This team is also very opaque, it's almost impossible |
52 |
to know what someone is working on. |
53 |
|
54 |
|
55 |
Lina Pezzella wrote: |
56 |
> -----BEGIN PGP SIGNED MESSAGE----- |
57 |
> Hash: SHA1 |
58 |
> |
59 |
> Our apologies for the tardiness of this e-mail; we have been preoccupied |
60 |
> with moving back to college this last week. |
61 |
> |
62 |
> We have thrown together some draft documentation[1] regarding our |
63 |
> expectations for ppc-macos arch testers. We have purposely neglected to |
64 |
> include policy and procedures for dealing with stable keywords pending |
65 |
> the current reevaluation of our decision to maintain them. For all |
66 |
> interested, please review the document and tell us what you think. The |
67 |
> faster we can all agree on policy and procedures, the faster we can get |
68 |
> arch testers on board. |
69 |
> |
70 |
> For those that missed the initial arch tester discussion, the hope is |
71 |
> that having a dedicated group of arch testers will improve QA as well as |
72 |
> free up developers to solve design and porting issues rather than |
73 |
> keyword requests and package testing. It is also a great place for |
74 |
> potential new developers to gain experience with the project. |
75 |
> |
76 |
> More policy and procedure documentation to come. |
77 |
> |
78 |
> - --Lina Pezzella && Hasan Khalil |
79 |
> Ebuild & Porting Co-Leads |
80 |
> Gentoo for OS X |
81 |
> |
82 |
> [1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html |
83 |
> -----BEGIN PGP SIGNATURE----- |
84 |
> Version: GnuPG v1.4.2 (Darwin) |
85 |
> |
86 |
> iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t |
87 |
> +xaXd/DKXUW0ZmJxomn8vYw= |
88 |
> =GZ6D |
89 |
> -----END PGP SIGNATURE----- |
90 |
> --gentoo-osx@g.o mailing list |
91 |
> |
92 |
|
93 |
-- |
94 |
Fabian Groffen |
95 |
Gentoo for Mac OS X |
96 |
-- |
97 |
gentoo-osx@g.o mailing list |