On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer <[email protected]> wrote: > > Yey, we're allowed to sometimes do revert games, if we're asking nicely > ... and the only way to stop the revert game is for QA to stand down. > We're allowed to send strongly-worded emails, but getting things baked > into policy is too radical.
So, here is how I reconcile this. There are basically two kinds of problems - technical problems, and people problems. We need to deal with both. I see QA as being primarily responsible for technical problems, and it should be staffed to deal with them. I'm fully supportive of it being a policy-creating body, with the Council being the place to vet any policies that seem controversial. If an ebuild has a deficiency, that's a technical problem - QA should step in. QA should also educate the maintainer so that they understand how to avoid the problem in the future. Suppose the maintainer refuses to take the problem seriously (whether they're just lazy, incompetent, or malicious). Now, that is a people problem, and really shouldn't be QA's responsibility to deal with beyond pointing it out to Comrel. Comrel should deal with people problems, and they should be staffed accordingly. They need the manpower so that they can deal with them efficiently. When QA says that a developer is not following a technical policy, Comrel should defer to them as this is their area of expertise. If either QA or Comrel gets out of hand there is always the appeal to Council, so neither body needs to be walking on eggshells or taking 18 months to decide to do something about a problem. If QA feels like Comrel isn't taking their complaints seriously, there is the Council - Comrel should be taking their concerns seriously. However, QA needs to recognize that people problems aren't always best solved with the use of command-line utilities. In then end we'll only get where we need to be if we work together, and avoid the passive-aggressive nonsense. If somebody feels that QA is out of line by all means put it on the Council agenda. Otherwise, devs need to do what they can to make the job of QA easier, and not harder. About the only time I really see need for "emergency suspension powers" is in the situation of some kind of hacking attempt. I'm not aware of any attack like this ever being mounted, but if it were the necessary action would involve a lot more than just suspending somebody's commit rights. Probably the best first action would be to disable all rsync/etc distribution, lock down cvs entirely, and then begin cleanup. If there is some kind of general standing problem of Comrel ignoring QA by all means let the Council know (assuming you can't just work it out with them). However, Comrel announced not all that long ago a general desire to enforce CoC with short bans/etc, and that they were interested in having a vital QA organization so that they have some kind of authority to rely on for technical questions. That certainly sounds like a good direction to me, so I don't want to dwell too much on the past. Bottom line - don't be afraid to do your job, and when something gets in the way speak up about it! Rich
