Gentoo Archives: gentoo-project

From: William Hubbs <williamh@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 14:29:06
Message-Id: 20160805142859.GA19008@linux1
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 by Rich Freeman
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies