On Mon, Jan 20, 2014 at 4:46 PM, Rich Freeman <[email protected]> wrote:
> 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. > > I can only think of one incident, and once we learned of the incident that developer was let go. > 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 > >
