| 1 |
On Saturday 11 of September 2010 20:51:56 justin wrote: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> is the following comment an adequate way to close bugs with |
| 5 |
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it |
| 6 |
> too. |
| 7 |
> |
| 8 |
> "" |
| 9 |
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) |
| 10 |
> ACCEPT_KEYWORDS="amd64" |
| 11 |
> |
| 12 |
> you mix stable & unstable -> your problem |
| 13 |
> "" |
| 14 |
|
| 15 |
This is common misconception. |
| 16 |
|
| 17 |
Let me quote myself from on of Diego's blogs, accusing me of not giving a crap |
| 18 |
about quality wrt FEATURES=test. |
| 19 |
|
| 20 |
Some people say that mixing testing and stable subtrees is ‘broken’ and not |
| 21 |
supported. |
| 22 |
|
| 23 |
It is because they apparently have no idea how package stabilization process |
| 24 |
works. |
| 25 |
|
| 26 |
‘tinderbox’ idea of full ~arch integration tests is broken by design! |
| 27 |
|
| 28 |
Why? Gentoo is distribution with rolling updates and packages being stabilized |
| 29 |
are hand picked from ~arch and integrated within existing stable environment |
| 30 |
(along with possible dependencies). |
| 31 |
|
| 32 |
Now the question arises – since Gentoo stable is our ultimate target release |
| 33 |
(and not ~arch) - what is the point in testing how these packages interact |
| 34 |
with full testing ~arch? The answer is NONE! |
| 35 |
|
| 36 |
If any, following tests should be run: |
| 37 |
|
| 38 |
- regression tests – ONLY within full stable arch, typical tinderbox of just |
| 39 |
chroot would fit there well, it could prevent issues like Gentoo LiveCD |
| 40 |
autobuilds failing since 8 April… |
| 41 |
|
| 42 |
- integration tests – in similar way stabilization process is performed: |
| 43 |
stable system as a base, picking packages or package sets for tests along with |
| 44 |
their possible dependencies (best version visible, if not visible within |
| 45 |
stable arch, then best visible within testing arch or some other algorithm, |
| 46 |
usually just relying on ebuild dependencies) and testing whether it works so |
| 47 |
that stabilization process is a formality. |
| 48 |
|
| 49 |
Running ~arch as 'test' platform is in many cases counter productive. |
| 50 |
|
| 51 |
-- |
| 52 |
regards |
| 53 |
MM |
Archives