1 |
On Fri, Aug 05, 2016 at 06:57:59AM -0400, Rich Freeman wrote: |
2 |
> On Thu, Aug 4, 2016 at 10:26 PM, William Hubbs <williamh@g.o> wrote: |
3 |
> > On Thu, Aug 04, 2016 at 07:25:52PM -0400, Rich Freeman wrote: |
4 |
> >> |
5 |
> >> I'm mostly fine with that, but I'd add just a requirement that |
6 |
> >> somebody does a quick sanity check on an otherwise-stable system. The |
7 |
> >> 30 days of testing is really only testing against dependencies that |
8 |
> >> are in ~arch. Granted, that will become less of a concern if all |
9 |
> >> those dependencies are also making their way to stable. |
10 |
> > |
11 |
> > Repoman will complain loudly if you try to stabilize something that |
12 |
> > doesn't have all of its reverse dependencies stabilized, so I think we |
13 |
> > are safe as long as people listen to repoman. I'm not advocating |
14 |
> > stabilizing things with ~ reverse dependencies, just trying to find a |
15 |
> > way to move stabilization along better than it has been moving. |
16 |
> > |
17 |
> |
18 |
> This only helps if the sanity check is correct. If a package has a |
19 |
> dependency on foo/bar, but it should have >=foo/bar-2, and ~arch is at |
20 |
> -2 and stable is at -1, then repoman will happily let you stabilize |
21 |
> your package even though it will break. Spending 30 days in testing |
22 |
> might or might not spot the issue, it depends on whether users running |
23 |
> mixed keywords test it. Since most testing users aren't running mixed |
24 |
> keywords they may not spot that the package breaks with bar-1. |
25 |
|
26 |
I think if you are doing this sort of testing you need to run a |
27 |
mostly stable system. If you are running full ~, you definitely would |
28 |
miss issues like this. I, for one, do not run full ~. |
29 |
|
30 |
I would actually recommend for devs that they run stable on everything |
31 |
except packages they maintain. If you do that, you catch issues like |
32 |
this. |
33 |
|
34 |
*snip* |
35 |
|
36 |
> Are the older packages actually hurting anybody? For the most common |
37 |
> arch (amd64) maintainers can just stabilize their own packages, so old |
38 |
> stable packages shouldn't be hurting maintainers (or if they are it is |
39 |
> self-inflicted...). |
40 |
|
41 |
I don't have the numbers in front of me, but from what I hear recently |
42 |
amd64 has become one of the more lagging architectures. I don't know if |
43 |
it is because most of our devs are running full ~ and are not set up to |
44 |
test against stable or if, like some I've talked to, it is just that |
45 |
they prefer a second set of eyes to go over a package before it is |
46 |
stabilized. |
47 |
|
48 |
Besides our maintainers keeping old packages around, we are doing a |
49 |
disservice to our stable users by offering them old software instead of |
50 |
keeping them as current as possible. |
51 |
|
52 |
William |