Don't put new packages through updates-testing
Hans de Goede
j.w.r.degoede at hhs.nl
Fri Jun 1 19:32:17 UTC 2007
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
More information about the fedora-devel-list
mailing list