1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA512 |
3 |
|
4 |
On 08/14/2011 05:07 PM, Thomas Sachau wrote: |
5 |
> Markos Chandras schrieb: |
6 |
>> On 08/14/2011 02:07 PM, Thomas Sachau wrote: |
7 |
>>> Markos Chandras schrieb: |
8 |
>>>> On 08/14/2011 01:15 PM, Thomas Sachau wrote: |
9 |
>>>>> Markos Chandras schrieb: |
10 |
>>>>>> Hi all, |
11 |
>>>>>> |
12 |
>>>>>> This is the first of the items I would like to discuss for |
13 |
>>>>>> the next Council agenda (or a later one). |
14 |
>>>>>> |
15 |
>>>>>> Some time ago, few people proposed to have Council |
16 |
>>>>>> appointed leaders for QA and DevRel. |
17 |
>>>> |
18 |
>>>>> My first question: Why is your proposal restricted to QA and |
19 |
>>>>> DevRel? |
20 |
>>>> |
21 |
>>>> Cause I believe these teams are crucial to the continuity of |
22 |
>>>> Gentoo project. |
23 |
>> |
24 |
>>> How do you weight one project against another one? I see it the |
25 |
>>> other way round: QA and DevRel are only important, if there is |
26 |
>>> some issue not resolved otherwise. But many other projects are |
27 |
>>> always important, since they have to maintain things |
28 |
>>> continuously. While the council could still decide, if DevRel or |
29 |
>>> QA are gone (they just take some workload away), you wont be able |
30 |
>>> to get the council to e.g. maintain our infrastructure, ebuilds |
31 |
>>> or docs. |
32 |
>> |
33 |
>> 1) If another project slacks, then bad luck for you. Just mask and |
34 |
>> remove the ebuilds ( see recent zope thread ). There is nothing we |
35 |
>> can do about that. |
36 |
> |
37 |
> If QA or DevRel slacks, this causes even less work, since they dont |
38 |
> even maintain ebuilds to mask and remove. It may result in less QA |
39 |
> fixes or less mediation between developers, but in any case, where |
40 |
> you need a decision, you could always call for the council. Those |
41 |
> projects do just some delegated work, which is of course nice, if it |
42 |
> comes to the daily work and also, because it reduces the work, that |
43 |
> needs to be done by the council. But neither is unreplaceable and the |
44 |
> decisions of both teams can already be checked by the council, so i |
45 |
> see no real requirement for additional bureaucracy for those 2 |
46 |
> specific teams. |
47 |
|
48 |
I am not talking ajust about decisions. If QA slacks then will then |
49 |
Council step up and maintain the QA in the portage? If devrel slacks |
50 |
then will the Council do all the recruitment/retirement? These projects |
51 |
are vital for the project. I don't know how to explain that in more details. |
52 |
|
53 |
> |
54 |
> Either you want to move more control to the council, then it should |
55 |
> do the checks and votes for all teams or you leave it like now, where |
56 |
> the teams do decide themselves. |
57 |
> |
58 |
>> 2) Infrastructure is a sensitive team, and does not deal with |
59 |
>> ebuild maintenance and portage directly. |
60 |
> |
61 |
> And if infra slacks? Bad luck for you, just mask and remove the |
62 |
> hardware? :-) |
63 |
Like I said, this is not related to portage QA. I only care about the |
64 |
/usr/portage/* parts and what users see from "outside" |
65 |
|
66 |
> |
67 |
>>>>>> I like the idea because this way the Council can ensure |
68 |
>>>>>> that the team is active or either force some activity in |
69 |
>>>>>> case the current leader slacks big time. |
70 |
>>>> |
71 |
>>>>> If there is noone active in a team, noone prevents other devs |
72 |
>>>>> to join the team and vote themselves for the lead. So even if |
73 |
>>>>> there is no activity, it should be no problem to get |
74 |
>>>>> activity, if someone is interested to do the work. |
75 |
>>>> Right now, you can't join any of these teams unless a lead |
76 |
>>>> approves you. Have a look at gentoo-qa ML. |
77 |
>> |
78 |
>>> Please re-read my lines. I talked about _noone being active_. The |
79 |
>>> QA team is not empty/inactive, neither is DevRel team |
80 |
>>> empty/inactive, so this does not apply to the current situation. |
81 |
>> Well, clearly we have a different definition for the word "active". |
82 |
>> If you think that QA is active then there is no reason for me to |
83 |
>> try to convince you for the opposite. |
84 |
> |
85 |
> Maybe you should first tell me, how you define activity for QA (and |
86 |
> DevRel)? |
87 |
Ok, and active QA team is a team that fixes severe and other QA problems |
88 |
within 24 hours. Moreover, an active QA team should be there 24/7 for |
89 |
someone who needs an advice for them or needs to complain about a |
90 |
developer that broke portage. If QA was active the breakages from |
91 |
Arfrever's commits would have been spotted months before a severe |
92 |
incident occurs. |
93 |
|
94 |
An active devrel, means fast procedures on conflict resolutions ( |
95 |
yngwin's case took 14 months and the decision was made after he was |
96 |
retired ), continuous retirement process, etc |
97 |
> |
98 |
>>>>> If the team is inactive and noone interested, the Council |
99 |
>>>>> wont be able to create any activity either, since they cannot |
100 |
>>>>> force anyone to do something. |
101 |
>>>> You can't just join a dead team and become a lead :). There |
102 |
>>>> are some bureaucracy procedures to follow. |
103 |
>> |
104 |
>>> You cant? who prevents you from doing so? And if there are just |
105 |
>>> some procedures to follow, this just means some initial |
106 |
>>> activity/workload to do so, but again: If the team is dead, who |
107 |
>>> could prevent you from joining it and then becoming the lead? |
108 |
>> Existing members, who claim to be active, may prevent you. Remember |
109 |
>> what happened last time Patrick tried to resurrect GMW, and all of |
110 |
>> a sudden, Joshua claimed that he can't do that because he wasn't |
111 |
>> the lead. Unless I misunderstand your definition for "dead" word. |
112 |
>> You mean empty project pages? Or just pages with 14 members and 0 |
113 |
>> commits/year? |
114 |
> |
115 |
> I would see a project as "dead", if there is no activity at all, also |
116 |
> there is a need for activity (like open bugs for an ebuild, which |
117 |
> never get processed or no newsletter sent out at all). |
118 |
This goes a bit OT, but if a project is dead the council MUST find a |
119 |
solution to that problem. Creating activity is not the only solution. |
120 |
Announcing the removal of dead projects along with their packages is a |
121 |
more realistic solution. Recent example, the zope herd that nobody |
122 |
notice they were dead until 2 days ago. Ugh... |
123 |
GWM, zope, media-optical, etc etc[1] are dead long time ago. |
124 |
|
125 |
http://www.gentoo.org/proj/en/metastructure/herds/herds.xml |
126 |
|
127 |
We need to come up with a solution for dead projects, but this is OT to |
128 |
the current thread. If someone wants to discuss this further please |
129 |
change the title and split the threads. |
130 |
|
131 |
- -- |
132 |
Regards, |
133 |
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 |
134 |
-----BEGIN PGP SIGNATURE----- |
135 |
Version: GnuPG v2.0.18 (GNU/Linux) |
136 |
|
137 |
iQIcBAEBCgAGBQJOR/WkAAoJEPqDWhW0r/LCJncQALJh9TJ/lPnl6yUkPS17Gxri |
138 |
kOpQRyOjYmlTpHBZe/hVsJ65Cj0n7H1t3/rjDIOfLMZQgiRUzK+s5AW03SjfNMwP |
139 |
w0W3SHGAZsYYXxQ3mX5zk8/JtV3LMWhG4JTNC4Set07PVqQQBN5Ky6w8h2fP8Ho5 |
140 |
sG4ZShVeXJtBMKwFyutB5Wjc67THxE+Hn5l8pOOvth+/rKbsnkue+mYvkIP+sicW |
141 |
kZukdyW66lclS0reTtOjqxHuvCI1nSiv/3lXZi7BiK/6b6TwBfTZL6BDlNgikBJe |
142 |
EoMF1SZrljbXYb7zhgpISC2ihuQAH3aMC7Nrr9NUuGVBUGZnJ9WFkiO7CTwGZ4Rn |
143 |
fB7fr1jlagSdzsjaf12VFKLjVS5fUNSQ6wK+pNY/lrmdNO8ioh1QPKmwrz11VT1H |
144 |
NCKOrMIzmRIa05dV9AIm6tx1174EnVpxopVlS11oGkKyWujPRxOimd8BzS7xZHTc |
145 |
nGVrktKXc3vLq/NAcYBpYZtYhvojZsJW7JR27h5GYYn6xh8Q4z4iL+6yRo3SmFCO |
146 |
9FYjIidZVcRK1zIF/e+B02peMgUJPLRIyxpV+LZgR2pQAOTRIePWjLr7tLfSMCnP |
147 |
iQjy4el/HjyHPfwhNETVDaKAoKLUwRM3teE2295z9ZlZ1k6Dh/IpZG1kOa1eszBf |
148 |
+uvke5EX06QtuPFGC3ah |
149 |
=D4Yx |
150 |
-----END PGP SIGNATURE----- |