Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree
Date: Mon, 15 Aug 2016 18:34:04
In Reply to: Re: [gentoo-dev] New Working Group established to evaluate the stable tree by William Hubbs
1 On Mon, Aug 15, 2016 at 1:31 PM, William Hubbs <williamh@g.o> wrote:
2 > I want to elaborate a bit more on this.
3 >
4 > On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote:
5 >> On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote:
6 >> > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
7 >> > > On 08/15/2016 04:19 PM, William Hubbs wrote:
8 >> > >> I'm very much for this as well. Themaintainer should be able to
9 >> > >> stabilize on all arches after the timeout. That would solve the primary
10 >> > >> concern I have about the stable tree lagging.
11 >> > >
12 >> > > It depends on the context, if it is not security related or fixing a
13 >> > > known bug, it can cause regression for stable users without much gain.
14 >
15 > The maintainer of the package is going to have the most intimate knowledge about
16 > these types of issues in the package, so I would rather have the maintainer
17 > make these types of decisions instead of restricting him with some global policy.
18 >
20 I'm fine with maintainers de-keywording packages on their own
21 initiative. However, if a maintainer hasn't even built a package on
22 an arch, they shouldn't be stabilizing it on that arch. That would
23 make the concept of stable meaningless. If it is just ~arch plus a
24 time delay, then we should just get rid of the stable keywords and
25 instead have portage just filter packages by the date they were
26 committed to ~arch.
28 I'd rather see maintainers just yank the last stable package and break
29 the depgraph and let the arch teams deal with the cleanup than have
30 them mark stuff stable without any testing at all. Or build a script
31 that does the keyword cleanup for them. De-keywording late stable
32 requests is a solution that is self-correcting. As packages are
33 reduced from the stable set then there are fewer stable requests and
34 the arch team is better able to focus on the ones they deem important.
35 Throwing more packages in stable that aren't actually stable just
36 makes that problem worse, and destroys whatever value the stable
37 keyword had on the arch. For small arch teams they really should be
38 focusing their time on core packages.
40 --
41 Rich