Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14
Date: Fri, 05 Aug 2016 10:58:04
Message-Id: CAGfcS_kBsnFc9T7qdHX4Eo7X=vRBmnU2V+1xeEihpaBpd9DsYg@mail.gmail.com
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 by William Hubbs
1 On Thu, Aug 4, 2016 at 10:26 PM, William Hubbs <williamh@g.o> wrote:
2 > On Thu, Aug 04, 2016 at 07:25:52PM -0400, Rich Freeman wrote:
3 >>
4 >> I'm mostly fine with that, but I'd add just a requirement that
5 >> somebody does a quick sanity check on an otherwise-stable system. The
6 >> 30 days of testing is really only testing against dependencies that
7 >> are in ~arch. Granted, that will become less of a concern if all
8 >> those dependencies are also making their way to stable.
9 >
10 > Repoman will complain loudly if you try to stabilize something that
11 > doesn't have all of its reverse dependencies stabilized, so I think we
12 > are safe as long as people listen to repoman. I'm not advocating
13 > stabilizing things with ~ reverse dependencies, just trying to find a
14 > way to move stabilization along better than it has been moving.
15 >
16
17 This only helps if the sanity check is correct. If a package has a
18 dependency on foo/bar, but it should have >=foo/bar-2, and ~arch is at
19 -2 and stable is at -1, then repoman will happily let you stabilize
20 your package even though it will break. Spending 30 days in testing
21 might or might not spot the issue, it depends on whether users running
22 mixed keywords test it. Since most testing users aren't running mixed
23 keywords they may not spot that the package breaks with bar-1.
24
25 I think we really ought to do SOME testing against the stable
26 dependencies. Otherwise you're going to have the occasional breakage,
27 and if people wanted occasional breakage they'd be running ~arch in
28 the first place.
29
30 I think it makes more sense to just get rid of stable than to make it
31 a stale version of testing.
32
33 Are the older packages actually hurting anybody? For the most common
34 arch (amd64) maintainers can just stabilize their own packages, so old
35 stable packages shouldn't be hurting maintainers (or if they are it is
36 self-inflicted...).
37
38 --
39 Rich

Replies