1 |
On Fri, Aug 05, 2016 at 07:31:33PM +0200, Kristian Fiskerstrand wrote: |
2 |
> On 08/04/2016 06:24 PM, William Hubbs wrote: |
3 |
> > I feel that our stable tree is so far behind on all |
4 |
> > architectures that we are doing our stable users a disservice, so I |
5 |
> > would like to open up a discussion here, and maybe some policy changes |
6 |
> > at the next meeting. |
7 |
> |
8 |
> Far behind isn't necessarily a problem as long as it doesn't have bugs, |
9 |
> in particular security related ones. Updating too often (without a good |
10 |
> reason) can also be annoying enough. |
11 |
> |
12 |
> > |
13 |
> > Ultimately, I think we need some form of automated stabilization, e.g. |
14 |
> > if a package version sits in ~ for 30 days and there are no blockers at |
15 |
> > that point, the new version should go automatically to stable on all |
16 |
> > architectures where there is a previous stable version. |
17 |
> |
18 |
> I LOUDLY disagree. The stable tree should not be compromised by such |
19 |
> automation, it is already bad enough without proper use-testing in some |
20 |
> cases. Stable isn't only about building properly. |
21 |
|
22 |
and that's why we don't commit straight to stable. people are supposed |
23 |
to be testing those ~arch versions for a while before they go stable. |
24 |
That testing should cover the use cases you are talking about and work |
25 |
out the bugs. Once that's done, we should be able to move the package to |
26 |
stable. |
27 |
|
28 |
William |