On Mon, 26 Mar 2007 07:52:25 -0700 (PDT) "Alec Warner" <[EMAIL PROTECTED]> wrote: > > On Sun, 25 Mar 2007 23:07:03 -0400 > > Seemant Kulleen <[EMAIL PROTECTED]> wrote: > >> Ciaran has brought attention to a very important thing -- QA seems > >> to take a backseat to a few things, and it is actually a little > >> disturbing that it does. > > > > I believe the QA team expect developers to *ask* when they want QA > > to intervene on a thing like this. There aren't enough people in QA > > to find every problem in the tree on their own... > > There is no motivation to ask if the developer in question doesn't > care about breaking the tree in the first place.
It doesn't have to be the developer in question who brings the issue to QA's attention... The problem, as I understand it, is this: The tree is big. There are lots of changes. Some of these changes are breakages. Some of these breakages can be detected automatically, which QA are fairly good at doing. Some of these breakages can't be, and QA won't know about these until someone reports it to them. Now, the tricky part. Some breakages, like this one, are the result of things that aren't directly tree changes, but rather an ongoing general change. Developers are generally expected to do the maintenance, but after a certain point, it's no longer worth waiting for them. QA can take over or authorise someone to take over in these situations, but only if an interested party steps up and says to QA "it's about time something gets done about this"... There's this general feeling that QA are expected to know everything and deal with every breakage. That isn't realistic, and I strongly suspect it's being used by certain people as a way of passing blame onto someone else. QA is, first and foremost, the responsibility of package maintainers. Secondly, it's the responsibility of arch teams. Only if both of those fail should the QA team get involved. -- Ciaran McCreesh
signature.asc
Description: PGP signature
