Fedora.us QA (was: Re: Prelink success story :))

[Michael Schwendt]

On Fri, 27 Feb 2004 00:02:28 -0500, Toshio wrote:

> I think the need to get feedback _on_a_QA_ is the heart of the problem
> right now.  QA'ers need mentoring to develop their skills.  Jef, how
> would you feel if some bug day we had experienced QA'ers team with new
> QA'ers to nitpick packages?  This could be a good first or second time
> QA experience: irc with a more experienced QA'er and pick apart the good
> and bad of a package.  Or we could assemble a team of experienced QA'ers
> to do second reviews once a new user did the first one.  This could be
> useful for a more advanced QA'er.  Kinda have a short apprenticeship
> followed by a test what you know phase.

The approach with the REVIEWED keyword belongs to a plan like this.
Still, it will need some to time to develop. Because we have upgrades to
process, too, and can't neglect them. And unfortunately, upgrades are not
trivial to approve, as either they fail somewhere or break something.

I've offered "team reviews" before, where someone would add me to Cc after
the first review and I would take a second look and be there if a second
publish vote is needed. I still offer being added to Cc in case of any
questions, too.

> What I would like to see (for both QA and packager) is an RPM Best
> Practices Handbook.  Accumulated wisdom about how to do things well
> organized by use cases with in depth justifications available as side
> passages for those who are curious why %{buildroot} and
> ${RPM_BUILD_ROOT} have such strong proponents on each side :-)

You have misunderstood the buildroot discussion. The reason why
$RPM_BUILD_ROOT is recommended is linked from within the QA checklist.

> As QA stands (with all volunteer QA'ers) we can't depend on a newbie
> doing first review and a seasoned vet doing the second review to figure
> out what the newbie left out.

So why is there no second newbie who joins the first newbie? As I put it,
both newbies can approve a package but still would need to get pass the
build system and the release manager. And if the package has bugs, what's
so wrong about learning from mistakes and bug reports? Hey, there are even
bug reports about missing desktop menu icons. ;)

> > 2. Provide some feedback. I QA'd some packages. I waited.
>
> I agree that reviews of work done encourage learning.

Yeah, but rather than waiting silently, why not post to fedora-devel-list
and request comments? More communication can help.

--