A Suggestion for Release Testing

[R Hill]

Scott Robert Ladd wrote:
> Joe Buck wrote:
>> With 4.0.0, compiling a complete GNU/Linux distribution reveals bugs
>> in GCC, but even more bugs in C++ software that is not valid C++.
>> Assuming we can get the distros to fix the latter set of problems...
> 
> I don't have a good solution for this problem, other than education.

The more the better. ;)  Actually, by the time 4.0.0 was released most 
of the packages in Gentoo that had issues with the new compiler had 
already been patched and tested.  There are some great gcc porting devs 
on board and a small independent group of users that use the weekly 
snapshots attempting to build a clean system in a chroot and patching up 
what we run into.

>> ...it would certainly be good for release testing if we built
>> complete distros, or significant chunks thereof.  It would be even
>> better if this could be coordinated with the people producing all
>> that software; I think that (for example) GCC and KDE could both do
>> better about trying each others' early code sooner than we do, and
>> communicate any problems found.
> 
> I'm hoping that creating a formal "core software" test might foster some
> of that communication. We have to start somewhere.

I use Gentoo's "system" target plus a few of the essentials like the 
kernel, xorg, Firefox ;), etc. as my smoketest.  Others use whatever 
they want or need.  Between all of us we end up covering a lot of the 
distro.  LFS and DIYL could be good models to look at as well.

While some of the Gentoo userbase isn't exactly helpful as far as 
development goes ;) there's still a lot of good work being done that's 
really not being used by anyone but us.  Patches go upstream of course, 
but we're in a good position to give an overall view of just how ready a 
particular release is to be let loose in public. Opening some lines of 
communication between GCC, the producers, and the users might be an 
asset to everybody.

--de. (currently working the hell out of RC1)