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: Thu, 04 Aug 2016 23:25:58
Message-Id: CAGfcS_=TwWJxjh+PUninJssMAVakUaRA5WGZ5cbSwz+XR0qQyA@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 6:22 PM, William Hubbs <williamh@g.o> wrote:
2 > On Thu, Aug 04, 2016 at 11:12:24PM +0300, Andrew Savchenko wrote:
3 >>
4 >> Thank you for caring about this issue. I had similar thoughts
5 >> myself, but was too slow on writing e-mail :) IMO stable tree has
6 >> three problems:
7 >> 1) too old packages
8 >> 2) too few packages
9 >> 3) stabilization often takes too long, such stable packages are
10 >> broken or buggy, while their unstable versions are fixed and work
11 >> fine. (It is not possible to fix all bugs without version or
12 >> revision bump, thus stabilization is needed to fix many bugs.)
13 >
14 > "too few packages" doesn't really affect things much, I'm more
15 > concerned about 1 and 3. If packages are not stable in the first place,
16 > that is because the maintainer hasn't requested stabilization, and that
17 > is a separate issue.
18
19 I'm less concerned with old (within reason) and few. I think the
20 primary criteria has to always be that the packages are reliable. If
21 somebody wants to make the tradeoff less reliability and fresher
22 packages they can just install testing.
23
24 >
25 > My proposal is saying that if you have a version of a package in ~,
26 > testing is being done, and at the end of the testing period (30 days at
27 > most), that new version in ~ should move to stable if there are no
28 > blockers. It would be up to you, the maintainer, or any users running
29 > the ~ version, to test and file bugs that block stabilization. These
30 > bugs could be detected automatically.
31 >
32
33 I'm mostly fine with that, but I'd add just a requirement that
34 somebody does a quick sanity check on an otherwise-stable system. The
35 30 days of testing is really only testing against dependencies that
36 are in ~arch. Granted, that will become less of a concern if all
37 those dependencies are also making their way to stable.
38
39 I'm not suggesting anything rigorous. However, it would be a bit
40 embarrassing to stabilize a package and find that it doesn't even
41 build, or which has some glaring issue. Build testing at least could
42 be automated, but I'm not sure if we need more than that. I'm not
43 entirely opposed to loosening things up on a trial basis and seeing
44 how it goes. However, if we're going to do that I wouldn't go nuts
45 with automation in case we decide to back off.
46
47 >
48 > We basically do. I don't have a link in front of me, but the council
49 > did make a decision allowing the removal of packages from the stable
50 > tree. It hasn't played out well though, because stable users expect
51 > that once a package is in the stable tree it will stay there until a
52 > newer version comes to the stable tree.
53
54 I'd have to look up the exact decision, but it was basically left to
55 maintainer discretion after some time lag. I think it is a useful
56 safety valve. If the maintainer feels that the stable version is
57 de-facto unmaintained and is causing problems, then we're not doing
58 stable users any favors by just leaving it on their systems. Just go
59 ahead and drop it and stable users can stick it in an overlay if they
60 know what they're doing, but they won't just live with some unknown
61 issue.
62
63 However, this shouldn't be done lightly. This isn't for that package
64 that is 60 days old. And it really should be the last resort when the
65 maintainer can't just stabilize it on their own (it is a bigger issue
66 for minor archs where hardware is less available and arch teams don't
67 have time to touch it).
68
69 >
70 > 2. if the package is all data files, or if it is written in an
71 > interpreted language e.g. python, perl, etc., Once the testing period
72 > has passed, the maintainer will be allowed to stabilize it on all arches
73 > that have a stable version without a stable request.
74
75 I believe there is already widespread agreement on this point. We've
76 talked about mechanisms to designate these packages but if we just
77 want to go with maintainer discretion we might be fine.
78
79 --
80 Rich

Replies