1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
|
5 |
On Sep 4, 2005, at 6:57 AM, Grobian wrote: |
6 |
|
7 |
> Although I like the arch testers (ATs) idea pretty much, I have |
8 |
> some questions: |
9 |
> |
10 |
> - Why have the 'low hanging fruit' bugs from before 2005 not been |
11 |
> resolved till I run through them a few weeks ago?. Most of them |
12 |
> were |
13 |
> small and had no USE flags. I expect the devs that had no time |
14 |
> to do |
15 |
> this in the past won't have time to do it when an AT has run over it |
16 |
|
17 |
This is exactly the point of arch testers. The idea is that AT's will |
18 |
evaluate those bugs and the developer will trust the AT's opinion and |
19 |
commit without redoing their work. It does not take much time to |
20 |
keyword and commit a package. The time drain is in compiling and |
21 |
testing the package. |
22 |
|
23 |
> In the end, the dev is responsible for the commit, not the AT, |
24 |
> hence I |
25 |
> would not be surprised if the dev does a (non USE flag extensive) |
26 |
> compilation on his own machine before committing to CVS. |
27 |
|
28 |
This is probably a good idea until a trust relationship between the |
29 |
dev and AT is established. For example, I rechecked most of your work |
30 |
as a developer candidate in the beginning, but after a week or so I |
31 |
stopped checking and committed what you indicated on trust. I would |
32 |
expect the same to happen with the new AT team. |
33 |
|
34 |
> A trust relationship between dev and AT is neccessary too and needs |
35 |
> to be |
36 |
> built. |
37 |
|
38 |
Absolutely. This will come from the AT doing good work and devs being |
39 |
prompt about responding to an AT's work. If each developer dedicated |
40 |
just an hour each week to going through AT work and committing what |
41 |
was indicated, I think it would be fairly easy to keep up with the |
42 |
load. You can do a large number of commits in an hour. |
43 |
|
44 |
> - Maybe AT's should be 'assigned' to one or two devs who are |
45 |
> responsible for committing the AT's work. This is a natural mentor |
46 |
> relationship as well as QA wise, it is obvious who is going to |
47 |
> punish |
48 |
> you if your work is not correct ;) |
49 |
|
50 |
I agree that we should have some sort of probation set up for AT's |
51 |
that do not do good work. I don't want to 'assign' AT's to devs as |
52 |
that implies that a dev is overseeing the AT's work. In order for |
53 |
AT's to help reduce our workload as devs they need to be a trusted/ |
54 |
independent group. Developers are not babysitters. |
55 |
|
56 |
> - This proposal assumes ATs have time, which devs apparently have not. |
57 |
|
58 |
Not true. If I didn't have time, I wouldn't be doing Gentoo. I choose |
59 |
to spend my time as a developer on larger projects then simply |
60 |
testing and keywording ebuilds. |
61 |
|
62 |
> I agree that the AT work is simple, but boring. Though I still like |
63 |
> to know why it hasn't been done in the past. |
64 |
|
65 |
It has been done by other archs and is recently becoming more |
66 |
mainstream within Gentoo. |
67 |
|
68 |
> - Assuming I'd have an AT or two assigned to me, |
69 |
|
70 |
That's not the way I'd like this to work. |
71 |
|
72 |
> I'd like to have the |
73 |
> freedom to give them more flesh if they are hungry for it, i.e. dive |
74 |
> into why something doesn't configure/build/compile/install and |
75 |
> try to |
76 |
> come up with a patch. |
77 |
|
78 |
Having AT's gives us a good way to evaluate potential new developers. |
79 |
My hope is that if an AT does good work and is interested in becoming |
80 |
a Gentoo developer, we can give them "more flesh", as you put it. It |
81 |
should be clear though that "more flesh" is not the responsibility of |
82 |
an AT. |
83 |
|
84 |
> Maybe this is dev dependant, but I think for an |
85 |
> AT it would be nice to know there is a road upstairs: if they're |
86 |
> good, |
87 |
> and do what they do very well, it would be nice if I wouldn't |
88 |
> have to |
89 |
> commit their work. (in other words: promote such AT to a dev) |
90 |
> On the |
91 |
> other hand, you still need the AT work to be done. |
92 |
|
93 |
Yes, promote the existing AT to a developer and get a new AT. Perhaps |
94 |
have the old AT mentor the new AT. These are all things to be decided |
95 |
upon as part of our policy on becoming a Gentoo for Mac OS X |
96 |
developer (which I think should also be written out instead of being |
97 |
unspoken). I feel that this is a subject for another policy page and |
98 |
another e-mail. For now, I'd like to focus on getting a group of AT's |
99 |
in place. |
100 |
|
101 |
> I think the draft is a good piece of work. I'm almost eager to |
102 |
> have one, like a PhD who gets an MSc assigned to him. My |
103 |
> experiences with some bug reporters who were also in IRC to fix |
104 |
> bugs using direct feedback from them is very productive, however if |
105 |
> I slam myself in the face and throw some cold water over my head I |
106 |
> feel myself forced to look at the issue from a much more |
107 |
> pessimistic point of view considering this team and the current |
108 |
> 'productiveness'. |
109 |
|
110 |
Don't assume that not seeing work from a developer means they're not |
111 |
working. For instance, as a result of recent emails on this list, |
112 |
Hasan and I have moved a large chunk of our time that was previously |
113 |
spent on porting/keywording e-mails to drafting documentation. |
114 |
Additionally, a lot of developers choose to work on long-term |
115 |
projects in an overlay and thus don't necessarily commit things to |
116 |
the portage tree proper on a regular basis. |
117 |
|
118 |
This being said, there are a good number of inactive developers. In a |
119 |
previous e-mail on this thread, Hasan and I explained our inability |
120 |
to take care of this problem without assuming the "Lead" position. |
121 |
Since there were no direct objections to our taking this position, we |
122 |
will make the appropriate changes to the project page[1] and begin |
123 |
conversation with devrel regarding our inactive developers. Hopefully |
124 |
this is still okay with everyone. More to follow regarding this in a |
125 |
new thread once we have more information. |
126 |
|
127 |
> Currently, we only discuss the way 'up', but maybe the way 'down' |
128 |
> should be in the picture too. An AT should be considered to be |
129 |
> 'active'. Where active means that such AT can do some useful work |
130 |
> on a regular base. (Note: this implicitly requires devs to be at |
131 |
> least as active as the AT.) If not, while there is work enough, |
132 |
> such AT should be removed. Might sound obvious, but if there are |
133 |
> no hard rules for it, noone will get removed. |
134 |
|
135 |
Agreed. So far, then, we need documentation/policy on the following: |
136 |
|
137 |
1) Inactivity (Developers and ATs) |
138 |
2) Probation for ATs (Probation for Devs is covered by devrel) |
139 |
3) Selection of New Developers / New ATs |
140 |
4) What each developer is working on (10,000ft overview) |
141 |
5) Specific/Misc Policy such as where to install python modules, |
142 |
package.mask usage, Unstable/Stable Keywording, etc |
143 |
|
144 |
All of this will be in the form of a Gentoo for Mac OS X policy |
145 |
handbook, which will take time (specifically (5) above). Suggestions |
146 |
for what should go in here would be highly valued. |
147 |
|
148 |
> Yes, nice idea, but I think we should look at the problem from |
149 |
> inside this very team first. I would consider the average |
150 |
> participation level very unhealthy. |
151 |
|
152 |
Again, please don't confuse lack of commits with lack of |
153 |
participation. Also note that we have only a handful of active |
154 |
developers. Once we agree upon policy for inactivity, we can make |
155 |
some progress with weeding out those that are not contributing. |
156 |
|
157 |
> This team is also very opaque, it's almost impossible to know what |
158 |
> someone is working on. |
159 |
|
160 |
Like we said, we'll address this shortly. We felt that AT's are more |
161 |
important than this right now. To give an idea: |
162 |
|
163 |
Kito is working on Darwin stuff. I'm sure he can elaborate if he |
164 |
cares to. |
165 |
Hasan is working on autotools and baselayout design issues for the |
166 |
collision-protect |
167 |
profiles as well as ipv6 support for qt. |
168 |
I am just completing my work with adding dylib support to ffmpeg. I |
169 |
also take care of sci-biology for ppc-macos. Next project is fixing |
170 |
esound. |
171 |
|
172 |
And of course, Hasan and I are both working on drafting documentation/ |
173 |
policy such as the AT Policy/Procedures draft we just sent out. If |
174 |
there is more documentation/policy that you feel is necessary, please |
175 |
start another thread and let all of us know. It's hard for us to tell |
176 |
what is needed since we've been here a while. |
177 |
|
178 |
Before discussing these other issues, however, can we all agree upon |
179 |
what is necessary to bring ATs on board? Is the documentation we have |
180 |
sufficient for that purpose, or is there more that needs to be added? |
181 |
(Note: policy on converting ATs to Devs is not needed yet.) |
182 |
|
183 |
- --Lina Pezzella |
184 |
Ebuild & Porting Co-Lead |
185 |
Gentoo for OS X |
186 |
|
187 |
[1] http://www.gentoo.org/proj/en/gentoo-alt/macos/index.xml |
188 |
|
189 |
> |
190 |
> Lina Pezzella wrote: |
191 |
> |
192 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
193 |
>> Hash: SHA1 |
194 |
>> Our apologies for the tardiness of this e-mail; we have been |
195 |
>> preoccupied with moving back to college this last week. |
196 |
>> We have thrown together some draft documentation[1] regarding our |
197 |
>> expectations for ppc-macos arch testers. We have purposely |
198 |
>> neglected to include policy and procedures for dealing with stable |
199 |
>> keywords pending the current reevaluation of our decision to |
200 |
>> maintain them. For all interested, please review the document and |
201 |
>> tell us what you think. The faster we can all agree on policy and |
202 |
>> procedures, the faster we can get arch testers on board. |
203 |
>> For those that missed the initial arch tester discussion, the hope |
204 |
>> is that having a dedicated group of arch testers will improve QA |
205 |
>> as well as free up developers to solve design and porting issues |
206 |
>> rather than keyword requests and package testing. It is also a |
207 |
>> great place for potential new developers to gain experience with |
208 |
>> the project. |
209 |
>> More policy and procedure documentation to come. |
210 |
>> - --Lina Pezzella && Hasan Khalil |
211 |
>> Ebuild & Porting Co-Leads |
212 |
>> Gentoo for OS X |
213 |
>> [1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html |
214 |
>> -----BEGIN PGP SIGNATURE----- |
215 |
>> Version: GnuPG v1.4.2 (Darwin) |
216 |
>> iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t |
217 |
>> +xaXd/DKXUW0ZmJxomn8vYw= |
218 |
>> =GZ6D |
219 |
>> -----END PGP SIGNATURE----- |
220 |
>> --gentoo-osx@g.o mailing list |
221 |
>> |
222 |
> |
223 |
> -- |
224 |
> Fabian Groffen |
225 |
> Gentoo for Mac OS X |
226 |
> -- |
227 |
> gentoo-osx@g.o mailing list |
228 |
> |
229 |
> |
230 |
|
231 |
|
232 |
-----BEGIN PGP SIGNATURE----- |
233 |
Version: GnuPG v1.4.2 (Darwin) |
234 |
|
235 |
iD8DBQFDG0lZNJ9STR9DbYERAh9XAKDgy4xA270naCwyzOnDOC8a/5cC2ACbBHnx |
236 |
FyQ6uGgz2kUN21unshZFxyM= |
237 |
=YPW3 |
238 |
-----END PGP SIGNATURE----- |
239 |
-- |
240 |
gentoo-osx@g.o mailing list |