1 |
On Sep 4, 2005, at 2:22 PM, Lina Pezzella wrote: |
2 |
|
3 |
> -----BEGIN PGP SIGNED MESSAGE----- |
4 |
> Hash: SHA1 |
5 |
> |
6 |
> |
7 |
> On Sep 4, 2005, at 6:57 AM, Grobian wrote: |
8 |
> |
9 |
> Don't assume that not seeing work from a developer means they're |
10 |
> not working. For instance, as a result of recent emails on this |
11 |
> list, Hasan and I have moved a large chunk of our time that was |
12 |
> previously spent on porting/keywording e-mails to drafting |
13 |
> documentation. |
14 |
|
15 |
Have you joined the docs team yet? |
16 |
|
17 |
> Additionally, a lot of developers choose to work on long-term |
18 |
> projects in an overlay and thus don't necessarily commit things to |
19 |
> the portage tree proper on a regular basis. |
20 |
|
21 |
Who is working on what where when? |
22 |
|
23 |
> |
24 |
> This being said, there are a good number of inactive developers. In |
25 |
> a previous e-mail on this thread, Hasan and I explained our |
26 |
> inability to take care of this problem without assuming the "Lead" |
27 |
> position. Since there were no direct objections to our taking this |
28 |
> position |
29 |
|
30 |
I think I have to object. |
31 |
|
32 |
The current direction is not ever going to be good for anyone, users |
33 |
or developers, and if it continues in the current direction it runs a |
34 |
high risk of being booted from Gentoo proper IMHO. I don't think any |
35 |
amount of policy, PR, elections, hand-waving, documentation, whatever |
36 |
is going to solve the problem. The best ideas I've seen proposed on |
37 |
this list have gotten little, if any, response from either of you. It |
38 |
seems apparent you think writing a bunch of policy and shuffling some |
39 |
names around on a webpage is going accomplish something. |
40 |
|
41 |
The macos project had docs, webpages, strategical operational |
42 |
structural senior team lead documentation managers and co-presidents, |
43 |
and /. announcements before the alpha version was even finished. |
44 |
There has been little progress made since a year ago, other than more |
45 |
ebuilds that install to / that no users want anyway (can you blame |
46 |
them?)... |
47 |
|
48 |
The g/fbsd team is waaaaaaay farther along than we are, and they |
49 |
still have 0 official docs/policies/etc. I don't believe that to be a |
50 |
coincidence. |
51 |
|
52 |
> , we will make the appropriate changes to the project page[1] and |
53 |
> begin conversation with devrel regarding our inactive developers. |
54 |
|
55 |
Let the council deal with inactive developers, IIRC there are |
56 |
provisions for exactly this problem. |
57 |
|
58 |
> Hopefully this is still okay with everyone. More to follow |
59 |
> regarding this in a new thread once we have more information. |
60 |
> |
61 |
>> Currently, we only discuss the way 'up', but maybe the way 'down' |
62 |
>> should be in the picture too. An AT should be considered to be |
63 |
>> 'active'. Where active means that such AT can do some useful work |
64 |
>> on a regular base. (Note: this implicitly requires devs to be at |
65 |
>> least as active as the AT.) If not, while there is work enough, |
66 |
>> such AT should be removed. Might sound obvious, but if there are |
67 |
>> no hard rules for it, noone will get removed. |
68 |
> |
69 |
> Agreed. So far, then, we need documentation/policy on the following: |
70 |
> |
71 |
> 1) Inactivity (Developers and ATs) |
72 |
|
73 |
This should be dealt with by the new council and/or devrel, but, how |
74 |
is anyones inactivity a problem (other than the obvious lack of |
75 |
manpower) ? Yes its annoying, but out of all the problems that need |
76 |
to be solved and work to be done, this seems like an odd thing to |
77 |
focus on. |
78 |
|
79 |
> 2) Probation for ATs (Probation for Devs is covered by devrel) |
80 |
|
81 |
I think there shouldn't be a separate set of rules for macos ATs, you |
82 |
should work with the other arch teams and establish something project |
83 |
wide. We are already in the corner, no reason to make macos even more |
84 |
of a corner case. |
85 |
|
86 |
> 3) Selection of New Developers / New ATs |
87 |
|
88 |
What needs to be documented that isn't already handled by devrel? |
89 |
|
90 |
> 4) What each developer is working on (10,000ft overview) |
91 |
|
92 |
http://cia.navi.cx/stats/author/<nick> and bugs.g.o are fairly |
93 |
telling... |
94 |
|
95 |
> 5) Specific/Misc Policy such as where to install python modules, |
96 |
> package.mask usage, Unstable/Stable Keywording, etc |
97 |
|
98 |
These things should be established before they are documented. Design |
99 |
by declaration is not a good idea. |
100 |
|
101 |
> |
102 |
> All of this will be in the form of a Gentoo for Mac OS X policy |
103 |
> handbook, which will take time (specifically (5) above). |
104 |
> Suggestions for what should go in here would be highly valued. |
105 |
|
106 |
I think the wiki is better suited for us at this point, as everything |
107 |
is in a fairly heavy state of flux. This also allows users to |
108 |
participate. |
109 |
|
110 |
> |
111 |
>> Yes, nice idea, but I think we should look at the problem from |
112 |
>> inside this very team first. I would consider the average |
113 |
>> participation level very unhealthy. |
114 |
> |
115 |
> Again, please don't confuse lack of commits with lack of |
116 |
> participation. Also note that we have only a handful of active |
117 |
> developers. Once we agree upon policy for inactivity, we can make |
118 |
> some progress with weeding out those that are not contributing. |
119 |
|
120 |
I haven't been too active in commits lately myself...RL,work and |
121 |
trouble with the 'big picture' of the project has slowed me down... |
122 |
|
123 |
> |
124 |
>> This team is also very opaque, it's almost impossible to know what |
125 |
>> someone is working on. |
126 |
> |
127 |
> Like we said, we'll address this shortly. We felt that AT's are |
128 |
> more important than this right now. To give an idea: |
129 |
> |
130 |
> Kito is working on Darwin stuff. I'm sure he can elaborate if he |
131 |
> cares to. |
132 |
|
133 |
I guess I don't work on macos stuff? I feel like I've been fairly |
134 |
vocal as to what I am / will be working on. Yes Darwin, but more-so |
135 |
macos as you can't have one without the other. For the past week, |
136 |
I've been getting familiar with the portage rewrite as much as |
137 |
possible.I'm also in the ppc and sound herds and maintain several |
138 |
sound packages, also working on a Darwin port for the pegasos and a |
139 |
LiveDVD designed for audio production. I try to keep my devaway |
140 |
current, there are times when I get too busy with work and life that |
141 |
will keep me away from gentoo for days at a time. I'm not really sure |
142 |
how I can be any more transparent...no, I won't blog :p |
143 |
|
144 |
> |
145 |
> Before discussing these other issues, however, can we all agree |
146 |
> upon what is necessary to bring ATs on board? Is the documentation |
147 |
> we have sufficient for that purpose, or is there more that needs to |
148 |
> be added? (Note: policy on converting ATs to Devs is not needed yet.) |
149 |
|
150 |
I think ATs are a great idea, but work better with a larger dev/user |
151 |
base. We couldn't even keep up with the bugs/patches/requests/reports |
152 |
submitted by our existing small base of users. The notion of 'not |
153 |
checking the ATs work' seems very odd, if an active dev is merely a |
154 |
proxy for a users work, that user should just be mentored and become |
155 |
an official dev. |
156 |
|
157 |
--Kito |
158 |
-- |
159 |
gentoo-osx@g.o mailing list |