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

Re: Don't put new packages through updates-testing

On Fri, 2007-06-01 at 16:18 +0200, Ralf Corsepius wrote:
> On Fri, 2007-06-01 at 09:47 -0400, Jesse Keating wrote:
> > On Friday 01 June 2007 09:14:23 Hans de Goede wrote:
> > > As already discussed on then maintainers list (using devel list for this as
> > > I see no reason to keep this on maintainers), the plan all of a sudden is
> > > to let new packages go through updates-testing.
> > > Yet another argument against making new-packages go through updates-testing
> > > is the fact that even if there were a QA team testing them, I wonder how
> > > they would test my latest batch of packages:
> > > avr-binutils
> > > avr-gcc
> > > avr-libc
> > > arm-gp2x-linux-kernel-headers
> > > arm-gp2x-linux-binutils
> > > arm-gp2x-linux-gcc
> > > arm-gp2x-linux-glibc
> > >
> > > Do they happen to have an avr microcontroller development kit handy for
> > > testing or a gp2x handheld? Any experience with programming those?
> > >
> > > Making package like these goto updates-testing is ridiculous.
> > 
> > So you're using one corner case package set with a limited user base to throw 
> > out the entire idea of getting some larger audience testing on new packages 
> > to a stable release.  Sounds like a great argument to me...
> It is, it demonstrates the flaw of your endeavor: 
> 1. You and the testers don't have the faintest idea how to test these
> packages: Probably 90% of all FE packages are in a similar boat:
> Specialized, small userbase and no knowledge on then in the testers team
> nor at RH.
> 2. There is no "community testers base" for such specialized packages,
> because these package are _new_ (rsp. not yet) in Fedora.
> 3. These packages are hugh and technically complex. They will never be
> "perfect" - There will always be bugs, it's only a matter if someone
> considers them severe enough.

Let's be a little more clear here - what the QA team actually does for
packages in updates-testing is *verification*. Check package sanity,
make sure programs don't segfault on startup, etc. 

I'm not expecting all testers to understand the functions of the
packages as well as their maintainers. But anyone can tell if you missed
some deps or your package doesn't start on x86_64.

For some extra background on this, you might like to read:


Attachment: signature.asc
Description: This is a digitally signed message part

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