| 1 |
Hi, everyone. |
| 2 |
|
| 3 |
Arch testing's relying on automation a lot these days. Not saying |
| 4 |
that's bad, if it improves the state of affairs. However, I have some |
| 5 |
concerns, based on what I've seen lately. |
| 6 |
|
| 7 |
On top of that, it seems that most of it still relies on proprietary |
| 8 |
software and we have no clue how *exactly* it works, and it's really, |
| 9 |
really hard to get a straight answer. |
| 10 |
|
| 11 |
So, my questions are: |
| 12 |
|
| 13 |
1. Is "runtime testing required" field being respected? Obviously not |
| 14 |
every package can be (sufficiently) tested via FEATURES=test, so we've |
| 15 |
added that fields. However, if arch testers just ignore it and push |
| 16 |
things stable based on pure build testing... |
| 17 |
|
| 18 |
2. How are kernels being tested? Given the speed with which new gentoo- |
| 19 |
sources stablereqs are handled, I really feel like "arch testing" there |
| 20 |
means "checking if sources install", and have little to do with working |
| 21 |
kernels. |
| 22 |
|
| 23 |
3. How does the automation handle packages that aren't trivially |
| 24 |
installable? I recall that in the past stablereqs were stalled for |
| 25 |
months without a single comment because automation couldn't figure out |
| 26 |
how to proceed, and nobody bothered reporting a problem. |
| 27 |
|
| 28 |
-- |
| 29 |
Best regards, |
| 30 |
Michał Górny |
Archives