[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:55 +0200, Hans de Goede wrote:
> Will Woods wrote:
> > 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.
> > 
> 1) I already verify my packages on x86_64 myself

Sure, and most maintainers do. And that's wonderful. It means that the
QA process will be very fast:

"Oh, look, one of Hans' packages! This will be easy!"
[mere minutes pass, most of which is downloading the packages]
"Yep, everything seems fine. That Hans is one great packager!"
[QA approves package, rel-eng signs it, all is right with the world]

So it really shouldn't slow *you* down much at all. But it should help
catch packaging / build mistakes made by *others* before they make it
into the repo.

> 2) starting libs is kinda hard
> 3) Most missing deps are subtile and do not necesarry show when just running an
>     app
> It would be more usefull to check build-logs for things like:
> -suspicious ./configure failures (due to missing BuildRequires)
> -64 bit suspecious compiler output like cast from different size integer to
>   pointer (this could actually be automated)
> Checking for 64 bit suspicious compiler warnings in my experience finds far 
> more 64 bit bugs then just a quick test run, unless those 64 bit bugs happen to 
> be in the straight quick test run path.

These are excellent recommendations. I'll be sure to put 'em up on the
QA pages when we start putting together our testing guidelines.



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]