| 1 |
On 08/05/2016 08:42 PM, William Hubbs wrote: |
| 2 |
>>> > > Ultimately, I think we need some form of automated stabilization, e.g. |
| 3 |
>>> > > if a package version sits in ~ for 30 days and there are no blockers at |
| 4 |
>>> > > that point, the new version should go automatically to stable on all |
| 5 |
>>> > > architectures where there is a previous stable version. |
| 6 |
>> > |
| 7 |
>> > I LOUDLY disagree. The stable tree should not be compromised by such |
| 8 |
>> > automation, it is already bad enough without proper use-testing in some |
| 9 |
>> > cases. Stable isn't only about building properly. |
| 10 |
> and that's why we don't commit straight to stable. people are supposed |
| 11 |
> to be testing those ~arch versions for a while before they go stable. |
| 12 |
> That testing should cover the use cases you are talking about and work |
| 13 |
> out the bugs. Once that's done, we should be able to move the package to |
| 14 |
> stable. |
| 15 |
|
| 16 |
It was recently a discussion in #-dev that could help on this, the |
| 17 |
automation can't be only build-testing, but if writing usage-tests |
| 18 |
(protocol, interface access testing etc for servers etc) automation |
| 19 |
would indeed be helpful. |
| 20 |
|
| 21 |
-- |
| 22 |
Kristian Fiskerstrand |
| 23 |
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net |
| 24 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives