| 1 |
On Tue, May 17, 2016 at 7:25 AM, Pallav Agarwal |
| 2 |
<pallavagarwal07@×××××.com> wrote: |
| 3 |
> Because we are already expecting an arch tester to conduct tests for the |
| 4 |
> package. And knowing what to test is something I expect to come more |
| 5 |
> easily from the maintainer. |
| 6 |
> |
| 7 |
|
| 8 |
It would come even more easily from upstream. My point is that |
| 9 |
upstream obviously doesn't consider it a priority, since if they did |
| 10 |
they'd be already supplying automated build scripts and we'd already |
| 11 |
be using them in the test phase. Maintainers generally don't consider |
| 12 |
them a priority either, since I imagine many existing upstream build |
| 13 |
scripts aren't implemented, and when they don't exist maintainers |
| 14 |
generally do not provide test plans. |
| 15 |
|
| 16 |
Again, I'm not objecting to the creation of this feature. I just |
| 17 |
think that it is unlikely to have a large impact on how things get |
| 18 |
done except perhaps for a couple packages or projects. For those |
| 19 |
packages/projects that do adopt this I'm sure there will be some real |
| 20 |
benefits. |
| 21 |
|
| 22 |
I'd also suggest having some way to break out short vs long tests. It |
| 23 |
might be beneficial to users to be able to run the tests on their own |
| 24 |
systems and not just limit this to arch testing. Obviously users are |
| 25 |
going to be less likely to want to run test scripts that take hours to |
| 26 |
run. Due to the nature of Gentoo it is unlikely that the environment |
| 27 |
used for testing by the AT is identical to the environment the |
| 28 |
packages will be run in. I'm not negating the value of testing prior |
| 29 |
to stabilization, but I don't agree that it completely takes the place |
| 30 |
of testing at time of installation and if we have automated test |
| 31 |
scripts, why not make them available to users? |
| 32 |
|
| 33 |
Of course, that would suggest that there is a potential benefit to be |
| 34 |
had from putting this into an EAPI. My suggestion would be to try to |
| 35 |
design this so that it would be appropriate for a future EAPI, but |
| 36 |
defer considering it for an EAPI until we see the feature getting |
| 37 |
enough use/demand to warrant this. |
| 38 |
|
| 39 |
-- |
| 40 |
Rich |
Archives