Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: Pacho Ramos <pacho@g.o>
Cc: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree
Date: Wed, 17 Aug 2016 13:07:46
In Reply to: Re: [gentoo-dev] New Working Group established to evaluate the stable tree by Pacho Ramos
1 On Wed, Aug 17, 2016 at 4:50 AM, Pacho Ramos <pacho@g.o> wrote:
2 >
3 > El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
4 > > [...]
5 > > Well, I wasn't suggesting that breaking the depgraph is great. Just
6 > > that I think it is better than calling things stable which aren't.
7 > >
8 > > A better approach is a script that does the keyword cleanup.
9 > >
10 > > So, if you want to reap an ebuild you run "destabilize
11 > > foo-1.2.ebuild". It searches the tree for all reverse deps and
12 > > removes stable keywords from those. Then you commit all of that in
13 > > one commit.
14 > >
15 > > If you want to be extra nice you stick it in a pull request in github
16 > > and point it out to the arch team and ask them if they're sure they
17 > > don't want to stabilize your package... :)
18 > >
19 >
20 > Well, the reason I was suggesting to allow maintainers to stabilize
21 > after the 90 days timeout over *current* policy of allowing the
22 > dekeywording is that the dekeywording is completely unrealistic to do
23 > as some packages have a huge amount of reverse deps. Even with the
24 > script (and, well, I would like to see that script existing... because
25 > we are having this issue for ages, and that is the reason that nobody
26 > is moving things to testing actively), you will find many many cases of
27 > packages having so many reverse dependencies that if you try to move it
28 > to testing it becomes soon a hell.
29 >
31 I'm not sure I agree. If it is scripted, then isn't it just a few
32 more cpu cycles?
34 Sure, I get that de-stabilizing one package could trigger
35 de-stabilizing 200 others, but the list is finite, and the algorithm
36 is reasonably straightforward. Just use the portage API and you can
37 find all the reverse deps for any package, using the same logic
38 portage will use. Granted, I could see it getting a little tricky
39 because you might be de-keywording multiple versions at once, and
40 those impact multiple versions at once, and you need to trace all of
41 those, preferably pruning the search space for duplicates as you go.
42 It actually sounds a little like my iterative map-reduce I used to
43 compare the git and cvs trees (map expands the dep tree by one level
44 from all the known impacted packages, reduce prunes duplicates, then
45 repeat until you've found all the leaves, probably by storing a tag in
46 the parent record when you've mapped it and found no children so that
47 future maps skip it).
49 But, I won't disagree that somebody has to write it.
51 >
52 > Then, my point it to allow the maintainer to keep stabilizing it
53 > *after* the 90 days timeout. If after that time, the arch team is
54 > unable to even reply, nobody has reported any build/runtime issues
55 > related with that arch, I would go ahead. Otherwise, it looks pretty
56 > evident to me that that arch is near to be used by nobody and maybe it
57 > should be moved completely to testing (or most of their packages moved
58 > to testing and only the core apps in stable).
59 >
61 Why even have a stable keyword? What does it even mean if everything
62 gets stabilized in 90 days whether it is tested or not, or whether it
63 even builds?
65 Take the degenerate case. Suppose an arch team is completely AWOL.
66 If we go with my route and de-stabilize packages then you end up with
67 an arch that is de-facto experimental with no stable packages (or
68 maybe @system only) after some period of time. If we instead
69 stabilize anything after 90 days if there is no response then the AWOL
70 arch team ends up having more stable packages than any other arch,
71 because they're the only ones not reporting bugs.
73 The whole point of a stable branch is that it is curated. It is
74 supposed to "just work." If changes make it in without any testing,
75 then it loses that quality, and it just becomes a stale testing
76 branch. I'd rather have stable be @system only so that you always
77 have a system that at-least boots and then go from there, or maybe
78 leave it to individual projects to maintain their own stable branches
79 with their own QA, than have stuff just dumped in stable without even
80 a build test, let alone some kind of runtime testing.
82 I'd even buy that maybe we don't need stable (though I think that the
83 minor arches are where it is most needed, at least for @system so that
84 users can actually boot their stage3s). However, it makes no sense to
85 go to the trouble to have a stable branch and not do anything to
86 ensure it is actually stable.
88 --
89 Rich