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@xxxxxxxxxxxxxxx>
