[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: fedora.us QA approval format

> ----------------------------------------------------------------
> Message: 1
> Date: Sat, 10 Apr 2004 14:04:27 +0200
> From: Aurelien Bompard <gauret free fr>
> Subject: Re: RFC: fedora.us QA approval format
> To: fedora-devel-list redhat com
> Message-ID: <c58ns1$k3r$1 sea gmane org>
> Content-Type: text/plain; charset=iso-8859-15
> Hi,
> Sorry to write back so late about that.
> Toshio wrote:
> > * I would get rid of the first line altogether.  Because these reviews
> > are going into bugzilla, the package name is already available.  And it
> > doesn't provide any information the build system needs.  Alternately,
> > you could make the first line:
> > <HASH> <SRPM>
> > so that it's useful for the build system.  (But see my next entry.)
> > 
> > * I would change Files to MD5sums (or MD5SUMS) because at sometime in
> > the future the build system may support other hash types and it would be
> > good for it to be able to easily tell which is which one this is.
> > 
> > * I would specify that the <SRPM> always comes first in the HASH
> > section.  This makes it easier for the release managers and the
> > buildsystem to parse the HASH-SRPM pairing from the other files.
> > It could also be separated by a blank line or other visible
> > demarcation.
> OK. I've updated http://fedora.us/wiki/QAFormat. How do you like it now ?
> > * Regarding the Sources lines: I'd include the full URL for the
> > tarball and say it comes from a canonical source rather than simply
> > "is valid".
> >   * http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is
> >     the canonical Source location
> Maybe the full URL is not necessary in the review, we could just add that
> canonicalness has been checked.
> I'm worried about the fact that bugzilla's mails are reformated to 80 (or
> some) characters columns, thus breaking GPG check. I try to avoid long
> lines, and an URL will probably be too long.
> > For the other source line, I'd want something like this:
> >   * Sources: bash-completion.profile appears to be correct and proper
> > 
> > My reasoning is that I don't care so much about whether I can download
> > the files off the internet  (More precisely: I only care if I can't.)
> > I do want to know what works  been done verifying the sources (which
> > canonicalness of source tarballs helps for the first one and looking
> > at the file helps for the second.)

I know that bugzilla has the 80 charachter limit and have been a
victimized more than once. The key for me with any review is
repeatability. I like having the full source url to make it easy to wget
and unroll the package for inspection in two easy steps.

Most of my reviews are very similar to what you have outlined. Maybe a
bit more verbose, if only to enable a second reviewer to replicate what
I have done. Hence checking the checker, if needed.

The other issue which I see missed often in reviews is not just a clean
install/remove check, but also upgrades, which I test as much as
possible. I tend to review packages I have already installed and use
regularly.  So many times I can make this check, but this is not 100% of
the time.

While I would not say it should be a hard and fast policy, upgrade
correctness is important, especially for stable repo packages. 

I just had that case with one of my own packages and it was not easy to
figure out. That is one of the hold ups on GIMP 2.0 in Fedora extras..
but I now think I have that solved.

Great work and thanks for adding this.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]