Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o, Richard Freeman <rich0@g.o>
Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree
Date: Wed, 17 Aug 2016 08:50:44
In Reply to: Re: [gentoo-dev] New Working Group established to evaluate the stable tree by Rich Freeman
1 El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
2 > [...]
3 > Well, I wasn't suggesting that breaking the depgraph is great.  Just
4 > that I think it is better than calling things stable which aren't.
5 >
6 > A better approach is a script that does the keyword cleanup.
7 >
8 > So, if you want to reap an ebuild you run "destabilize
9 > foo-1.2.ebuild".  It searches the tree for all reverse deps and
10 > removes stable keywords from those.  Then you commit all of that in
11 > one commit.
12 >
13 > If you want to be extra nice you stick it in a pull request in github
14 > and point it out to the arch team and ask them if they're sure they
15 > don't want to stabilize your package...  :)
16 >
18 Well, the reason I was suggesting to allow maintainers to stabilize
19 after the 90 days timeout over *current* policy of allowing the
20 dekeywording is that the dekeywording is completely unrealistic to do
21 as some packages have a huge amount of reverse deps. Even with the
22 script (and, well, I would like to see that script existing... because
23 we are having this issue for ages, and that is the reason that nobody
24 is moving things to testing actively), you will find many many cases of
25 packages having so many reverse dependencies that if you try to move it
26 to testing it becomes soon a hell. 
28 The main issue is that, once you start dekeywording one package, you
29 jump to, for example, dekeywording another 3 reverse deps, then you
30 need to continue with the reverse deps of that reverse deps... and at
31 the end, it's completely impossible to manage it (I still remember how
32 hard was to move to testing most of Gnome... and we even were lucky as
33 we were able to do that with the jump to Gnome3).
35 Then, my point it to allow the maintainer to keep stabilizing it
36 *after* the 90 days timeout. If after that time, the arch team is
37 unable to even reply, nobody has reported any build/runtime issues
38 related with that arch, I would go ahead. Otherwise, it looks pretty
39 evident to me that that arch is near to be used by nobody and maybe it
40 should be moved completely to testing (or most of their packages moved
41 to testing and only the core apps in stable).