Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: Rich Freeman <rich0@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 14:25:53
In Reply to: Re: [gentoo-dev] New Working Group established to evaluate the stable tree by Rich Freeman
1 El mié, 17-08-2016 a las 09:07 -0400, Rich Freeman escribió:
2 > I'm not sure I agree.  If it is scripted, then isn't it just a few
3 > more cpu cycles?
5 Well... until I see that script, I won't trust it. We are for a long
6 time supposedly allowing people to move things to testing after 90 days
7 and that is not working at all because of that. Simply try to go to our
8 current pending gnome stabilization, and you will see how difficult
9 does it turn (for example, another issue is with the optional reverse
10 dependencies, that would require to use.mask some USE flags for some
11 packages in some arches).
13 Once that script is ready... I am unsure about why are we even
14 discussing this as, after that dekeywording task can be feasible after
15 90 days, the picture in all exotic arches with change so much that we
16 would need to meet again in some months to evaluate the result 
18 The problem is that I don't think that is really feasible... and
19 looking to that script still being unavailable and we still discussing
20 about how to improve this makes me think it's a harder issue to achieve
21 :(
23 > Why even have a stable keyword?  What does it even mean if everything
24 > gets stabilized in 90 days whether it is tested or not, or whether it
25 > even builds?
26 >
27 Well, personally I don't think why many of that arches are supposedly
28 still having a reliable stable tree. Most of them are relying on Ago
29 doing most of the work (that is mostly buildtime testing... and I have
30 no issue with that, as adding also runtime testing to all the packages
31 and arches is completely unrealistic). Anyway the "stable keyword"
32 would still give the packages 90 days of being in the tree (at least)
33 for the hypothetical bugs to appear. If they don't appear, maybe they
34 don't exist (like in most cases) or, in the worst case, that arches are
35 so few used that I am sure the burden would be high enough.
38 > Take the degenerate case.  Suppose an arch team is completely AWOL.
39 > If we go with my route and de-stabilize packages then you end up with
40 > an arch that is de-facto experimental with no stable packages (or
41 > maybe @system only) after some period of time.  If we instead
42 > stabilize anything after 90 days if there is no response then the
43 > AWOL
44 > arch team ends up having more stable packages than any other arch,
45 > because they're the only ones not reporting bugs.
47 Well, if we have the script, I am the first one preferring your
48 route... but that route is of dekeywording stuff is allowed for a long
49 time and we still have nothing, then, until that script is even a
50 draft, I don't consider it a real option.