| 1 |
On 08/05/2016 02:45 PM, Kristian Fiskerstrand wrote: |
| 2 |
> On 08/05/2016 08:42 PM, William Hubbs wrote: |
| 3 |
>>>>>> Ultimately, I think we need some form of automated stabilization, e.g. |
| 4 |
>>>>>> if a package version sits in ~ for 30 days and there are no blockers at |
| 5 |
>>>>>> that point, the new version should go automatically to stable on all |
| 6 |
>>>>>> architectures where there is a previous stable version. |
| 7 |
>>>> |
| 8 |
>>>> I LOUDLY disagree. The stable tree should not be compromised by such |
| 9 |
>>>> automation, it is already bad enough without proper use-testing in some |
| 10 |
>>>> cases. Stable isn't only about building properly. |
| 11 |
>> and that's why we don't commit straight to stable. people are supposed |
| 12 |
>> to be testing those ~arch versions for a while before they go stable. |
| 13 |
>> That testing should cover the use cases you are talking about and work |
| 14 |
>> out the bugs. Once that's done, we should be able to move the package to |
| 15 |
>> stable. |
| 16 |
> |
| 17 |
> It was recently a discussion in #-dev that could help on this, the |
| 18 |
> automation can't be only build-testing, but if writing usage-tests |
| 19 |
> (protocol, interface access testing etc for servers etc) automation |
| 20 |
> would indeed be helpful. |
| 21 |
> |
| 22 |
|
| 23 |
Isn't the src_test phase psuedo runtime testing? I'm not sure that us |
| 24 |
developing test suites for upstreams is a good use of our time. I mean, |
| 25 |
yes, it would improve the upstream projects where they accept it (which |
| 26 |
is good for all), but I feel it detracts from what Gentoo developers are |
| 27 |
doing (for Gentoo) |
| 28 |
|
| 29 |
-- |
| 30 |
NP-Hardass |
Archives