1 |
On Mon, Jan 20, 2014 at 4:46 PM, Rich Freeman <rich0@g.o> wrote: |
2 |
|
3 |
> On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer <patrick@g.o> wrote: |
4 |
> > |
5 |
> > Yey, we're allowed to sometimes do revert games, if we're asking nicely |
6 |
> > ... and the only way to stop the revert game is for QA to stand down. |
7 |
> > We're allowed to send strongly-worded emails, but getting things baked |
8 |
> > into policy is too radical. |
9 |
> |
10 |
> So, here is how I reconcile this. There are basically two kinds of |
11 |
> problems - technical problems, and people problems. We need to deal |
12 |
> with both. I see QA as being primarily responsible for technical |
13 |
> problems, and it should be staffed to deal with them. I'm fully |
14 |
> supportive of it being a policy-creating body, with the Council being |
15 |
> the place to vet any policies that seem controversial. |
16 |
> |
17 |
> If an ebuild has a deficiency, that's a technical problem - QA should |
18 |
> step in. QA should also educate the maintainer so that they |
19 |
> understand how to avoid the problem in the future. |
20 |
> |
21 |
> Suppose the maintainer refuses to take the problem seriously (whether |
22 |
> they're just lazy, incompetent, or malicious). Now, that is a people |
23 |
> problem, and really shouldn't be QA's responsibility to deal with |
24 |
> beyond pointing it out to Comrel. |
25 |
> |
26 |
> Comrel should deal with people problems, and they should be staffed |
27 |
> accordingly. They need the manpower so that they can deal with them |
28 |
> efficiently. When QA says that a developer is not following a |
29 |
> technical policy, Comrel should defer to them as this is their area of |
30 |
> expertise. If either QA or Comrel gets out of hand there is always |
31 |
> the appeal to Council, so neither body needs to be walking on |
32 |
> eggshells or taking 18 months to decide to do something about a |
33 |
> problem. If QA feels like Comrel isn't taking their complaints |
34 |
> seriously, there is the Council - Comrel should be taking their |
35 |
> concerns seriously. However, QA needs to recognize that people |
36 |
> problems aren't always best solved with the use of command-line |
37 |
> utilities. |
38 |
> |
39 |
> In then end we'll only get where we need to be if we work together, |
40 |
> and avoid the passive-aggressive nonsense. If somebody feels that QA |
41 |
> is out of line by all means put it on the Council agenda. Otherwise, |
42 |
> devs need to do what they can to make the job of QA easier, and not |
43 |
> harder. |
44 |
> |
45 |
> About the only time I really see need for "emergency suspension |
46 |
> powers" is in the situation of some kind of hacking attempt. I'm not |
47 |
> aware of any attack like this ever being mounted, but if it were the |
48 |
> necessary action would involve a lot more than just suspending |
49 |
> somebody's commit rights. Probably the best first action would be to |
50 |
> disable all rsync/etc distribution, lock down cvs entirely, and then |
51 |
> begin cleanup. |
52 |
> |
53 |
> |
54 |
I can only think of one incident, and once we learned of the incident that |
55 |
developer was let go. |
56 |
|
57 |
|
58 |
|
59 |
> If there is some kind of general standing problem of Comrel ignoring |
60 |
> QA by all means let the Council know (assuming you can't just work it |
61 |
> out with them). However, Comrel announced not all that long ago a |
62 |
> general desire to enforce CoC with short bans/etc, and that they were |
63 |
> interested in having a vital QA organization so that they have some |
64 |
> kind of authority to rely on for technical questions. That certainly |
65 |
> sounds like a good direction to me, so I don't want to dwell too much |
66 |
> on the past. |
67 |
> |
68 |
> Bottom line - don't be afraid to do your job, and when something gets |
69 |
> in the way speak up about it! |
70 |
> |
71 |
> Rich |
72 |
> |
73 |
> |