1 |
Markos Chandras schrieb: |
2 |
> On 08/14/2011 05:07 PM, Thomas Sachau wrote: |
3 |
>> Markos Chandras schrieb: |
4 |
>>> On 08/14/2011 02:07 PM, Thomas Sachau wrote: |
5 |
>>>> Markos Chandras schrieb: |
6 |
>>>>> On 08/14/2011 01:15 PM, Thomas Sachau wrote: |
7 |
>>>>>> Markos Chandras schrieb: |
8 |
>>>>>>> Hi all, |
9 |
>>>>>>> |
10 |
>>>>>>> This is the first of the items I would like to discuss for |
11 |
>>>>>>> the next Council agenda (or a later one). |
12 |
>>>>>>> |
13 |
>>>>>>> Some time ago, few people proposed to have Council |
14 |
>>>>>>> appointed leaders for QA and DevRel. |
15 |
>>>>> |
16 |
>>>>>> My first question: Why is your proposal restricted to QA and |
17 |
>>>>>> DevRel? |
18 |
>>>>> |
19 |
>>>>> Cause I believe these teams are crucial to the continuity of |
20 |
>>>>> Gentoo project. |
21 |
>>> |
22 |
>>>> How do you weight one project against another one? I see it the |
23 |
>>>> other way round: QA and DevRel are only important, if there is |
24 |
>>>> some issue not resolved otherwise. But many other projects are |
25 |
>>>> always important, since they have to maintain things |
26 |
>>>> continuously. While the council could still decide, if DevRel or |
27 |
>>>> QA are gone (they just take some workload away), you wont be able |
28 |
>>>> to get the council to e.g. maintain our infrastructure, ebuilds |
29 |
>>>> or docs. |
30 |
>>> |
31 |
>>> 1) If another project slacks, then bad luck for you. Just mask and |
32 |
>>> remove the ebuilds ( see recent zope thread ). There is nothing we |
33 |
>>> can do about that. |
34 |
> |
35 |
>> If QA or DevRel slacks, this causes even less work, since they dont |
36 |
>> even maintain ebuilds to mask and remove. It may result in less QA |
37 |
>> fixes or less mediation between developers, but in any case, where |
38 |
>> you need a decision, you could always call for the council. Those |
39 |
>> projects do just some delegated work, which is of course nice, if it |
40 |
>> comes to the daily work and also, because it reduces the work, that |
41 |
>> needs to be done by the council. But neither is unreplaceable and the |
42 |
>> decisions of both teams can already be checked by the council, so i |
43 |
>> see no real requirement for additional bureaucracy for those 2 |
44 |
>> specific teams. |
45 |
> |
46 |
> I am not talking ajust about decisions. If QA slacks then will then |
47 |
> Council step up and maintain the QA in the portage? If devrel slacks |
48 |
> then will the Council do all the recruitment/retirement? These projects |
49 |
> are vital for the project. I don't know how to explain that in more details. |
50 |
|
51 |
Every developer is responsible for the QA of the packages he maintains. There are of course some |
52 |
mistakes happening and sometimes someone does something wrong (intentionally or not), but if there |
53 |
is no active QA team, this just means, that the users will hit those issues and report them. While |
54 |
this is not the best way, it still does not mean the end of Gentoo. |
55 |
While DevRel currently only contains members of recruiters and undertakers, this does not have to |
56 |
stay that way. Either some recruiter/undertaker could refuse to do additional DevRel work or other |
57 |
developers not involved in recruitment/retirement could join the DevRel project. |
58 |
|
59 |
So while recruiters are vital to Gentoo, imho this is not true for DevRel. |
60 |
|
61 |
>>> 2) Infrastructure is a sensitive team, and does not deal with |
62 |
>>> ebuild maintenance and portage directly. |
63 |
> |
64 |
>> And if infra slacks? Bad luck for you, just mask and remove the |
65 |
>> hardware? :-) |
66 |
> Like I said, this is not related to portage QA. I only care about the |
67 |
> /usr/portage/* parts and what users see from "outside" |
68 |
|
69 |
If the master rsync server refuses to run, this will have an impact at what users see from "outside" ;-) |
70 |
|
71 |
[SNIP] |
72 |
> |
73 |
>> Maybe you should first tell me, how you define activity for QA (and |
74 |
>> DevRel)? |
75 |
> Ok, and active QA team is a team that fixes severe and other QA problems |
76 |
> within 24 hours. Moreover, an active QA team should be there 24/7 for |
77 |
> someone who needs an advice for them or needs to complain about a |
78 |
> developer that broke portage. If QA was active the breakages from |
79 |
> Arfrever's commits would have been spotted months before a severe |
80 |
> incident occurs. |
81 |
|
82 |
If your requirement for active QA is that high, i have to tell you, that practially you will never |
83 |
get the needed manpower together to meet those requirements. |