Don't put new packages through updates-testing

[Hans de Goede]

Will Woods wrote:
> 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.
> 

If things will actually work with that, iow if packages in updates-testing will 
get QA approved in 1-2 workdays in general and then move to updates, then I 
think updates-testing will be a good idea, and the additional QA will be worth 
the delay.

What I'm against is the old updates-testing ways where a package would just 
linger for a week (esp if its a new package!) and the get moved to updates 
without having seen much testing if any at all. That way just adds a week delay 
without much benefits.



>> 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.
> 

I'm glad you like them, also always a good idea is running rpmlint, and for 
small apps trying to run them with LD_PRELOAD=libefence.so (do not try this for 
big apps)

Regards,

Hans