On Fri, 2004-02-27 at 06:34, Michael Schwendt wrote:
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.
Great! If we had something written about "Michael Schwendt has a
standing invitation to ask him to do a second review to help you figure
out what you've missed (and incidentally get the package 100% reviewed)"
would be great. Getting other people to sign on to do this would be
great 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.
Nope. I've read that, including the part where Jef says that he's not
likely to change it anytime soon even though it's a mis-feature
(paraphrased.)
Added to that is the fact that it's a _build_ problem. Already created
binary RPMS have no problems. If Jef announces that %{buildroot} is
deprecated we can start making this a showstopper and kill all
references as an evolutionary process.
> 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. ;)
True. Maybe I'm the perfectionist on this list :-)
> > 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.
But what if you and dag get into
another shouting match? :-) Seriously,
this is a good point. We should document it, though. I wasn't sure
this would be an appropriate thing to post here until recently.
-Toshio
--
Toshio <toshio(a)tiki-lounge.com>