On Mon, 29 Dec 2003 04:00:40 +0000
Tom Payne <twp@gentoo.org> wrote:

> Problems solved:
> 
> Arch leads no longer have to test every single ebuild that comes there
> way-- non x86 arches get package updates quicker with reduced workload
> for arch leads.

If we can do this without a loss of the Q in QA, then I'm all for it :)

One alternative that is becoming available to developers are the
development/release engineering boxes that are cropping up.

For a lot of programs out there, it's not hard to test their functionality
remotely (though GUI applications can be a bit harder).  I imagine having
one or two people per herd with accounts on these various boxes would help
improve QA substantially.

Granted at the current time, not all arches have a publically
available test machine or two, but it definitely decreases the
amount of work on the arch devs and the "no news is good news"
stablization of ebuilds that happens now.
 
> No need to write unit tests for packages to help arch leads (lots of
> work and hard to do in some cases (e.g. interactive progs)).

Test cases don't necessarily need to be automated.  A simple list of
instructions to verify functionality that a dev could run wound be
acceptable (to me).  

For example

1) Do operation a
2) Do operation b
3) Expect result c

> New problems:
>
> Might result in broken software being installed.

I'd like to avoid this if at all possible.  All software in the tree,
even if it's marked ~arch, is supposed to work.  The fact that ~arch
things are broken is bad, but if a package gets to arch broken or still
broken is even worse, and reflects poorly on Gentoo as a whole.

> Feedback please. I advocate this approach for 'minor' packages, i.e.
> nothing fundamental to the working of the system. It's more suitable for
> scripting language libraries and minor applications (e.g. obscure window
> managers).

While most of the time, packages aren't problematic on non-x86 arches,
there do crop up those that have abnormal behavior.  Whether it's unable
to compile or has undesired/broken functionality once compiled/installed. 

I'm a bit more open to packages that are scripts, but I have yet to meet a
language that is truly as cross-platform compatible as they all claim to
be (not that I'm any kind of official reviewer or have run into every
language out there).

However, if something like this is implemented, I would ask that programs
that need to be compiled not be put into this list.  If a problem is going
to crop up, it'll be here, and often times Makefiles don't fail correctly
if something cannot build (for instance try over-optimizing
net-firewall/fwbuilder and then find the fwbuilder executable after it has
installed).


My (non-refundable) $0.02,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead