On Saturday 11 of September 2010 20:51:56 justin wrote: > Hi all, > > is the following comment an adequate way to close bugs with > RESOLVED/INVALID? If so, I will change the way I handle bugs and use it > too. > > "" > virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) > ACCEPT_KEYWORDS="amd64" > > you mix stable & unstable -> your problem > ""
This is common misconception. Let me quote myself from on of Diego's blogs, accusing me of not giving a crap about quality wrt FEATURES=test. Some people say that mixing testing and stable subtrees is ‘broken’ and not supported. It is because they apparently have no idea how package stabilization process works. ‘tinderbox’ idea of full ~arch integration tests is broken by design! Why? Gentoo is distribution with rolling updates and packages being stabilized are hand picked from ~arch and integrated within existing stable environment (along with possible dependencies). Now the question arises – since Gentoo stable is our ultimate target release (and not ~arch) - what is the point in testing how these packages interact with full testing ~arch? The answer is NONE! If any, following tests should be run: - regression tests – ONLY within full stable arch, typical tinderbox of just chroot would fit there well, it could prevent issues like Gentoo LiveCD autobuilds failing since 8 April… - integration tests – in similar way stabilization process is performed: stable system as a base, picking packages or package sets for tests along with their possible dependencies (best version visible, if not visible within stable arch, then best visible within testing arch or some other algorithm, usually just relying on ebuild dependencies) and testing whether it works so that stabilization process is a formality. Running ~arch as 'test' platform is in many cases counter productive. -- regards MM
signature.asc
Description: This is a digitally signed message part.
