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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
