Gentoo Archives: gentoo-dev

From: Raymond Jennings <shentino@×××××.com>
To: gentoo-dev <gentoo-dev@l.g.o>
Cc: Richard Freeman <rich0@g.o>
Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree
Date: Thu, 18 Aug 2016 07:33:40
In Reply to: Re: [gentoo-dev] New Working Group established to evaluate the stable tree by Pacho Ramos
1 Strict compliance with the handbook would seem to forbid having a stable
2 package depend on an unstable package, and if you have to downgrade a
3 dependency and it causes a cascade, I would opine, that, perhaps, the
4 package in question should not have been stabilized to begin with.
6 That said, I as a user have noticed that packages tend to stall in
7 stabilization for awhile.
9 What about a script that can rank ~arch keyworded packages by some sort of
10 priority?
12 Maybe point out which one has the most reverse dependencies? Or which one
13 has been stuck in ~arch the longest? Or some sort of scoring mechanism
14 that can flag the most urgently needed stabilizations?
16 Come to think of it, I think debian has a system that flags the most
17 popular packages. Does gentoo have a way to note what packages are most
18 important?
20 On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ramos <pacho@g.o> wrote:
22 > El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
23 > > [...]
24 > > Well, I wasn't suggesting that breaking the depgraph is great. Just
25 > > that I think it is better than calling things stable which aren't.
26 > >
27 > > A better approach is a script that does the keyword cleanup.
28 > >
29 > > So, if you want to reap an ebuild you run "destabilize
30 > > foo-1.2.ebuild". It searches the tree for all reverse deps and
31 > > removes stable keywords from those. Then you commit all of that in
32 > > one commit.
33 > >
34 > > If you want to be extra nice you stick it in a pull request in github
35 > > and point it out to the arch team and ask them if they're sure they
36 > > don't want to stabilize your package... :)
37 > >
38 >
39 > Well, the reason I was suggesting to allow maintainers to stabilize
40 > after the 90 days timeout over *current* policy of allowing the
41 > dekeywording is that the dekeywording is completely unrealistic to do
42 > as some packages have a huge amount of reverse deps. Even with the
43 > script (and, well, I would like to see that script existing... because
44 > we are having this issue for ages, and that is the reason that nobody
45 > is moving things to testing actively), you will find many many cases of
46 > packages having so many reverse dependencies that if you try to move it
47 > to testing it becomes soon a hell.
48 >
49 > The main issue is that, once you start dekeywording one package, you
50 > jump to, for example, dekeywording another 3 reverse deps, then you
51 > need to continue with the reverse deps of that reverse deps... and at
52 > the end, it's completely impossible to manage it (I still remember how
53 > hard was to move to testing most of Gnome... and we even were lucky as
54 > we were able to do that with the jump to Gnome3).
55 >
56 > Then, my point it to allow the maintainer to keep stabilizing it
57 > *after* the 90 days timeout. If after that time, the arch team is
58 > unable to even reply, nobody has reported any build/runtime issues
59 > related with that arch, I would go ahead. Otherwise, it looks pretty
60 > evident to me that that arch is near to be used by nobody and maybe it
61 > should be moved completely to testing (or most of their packages moved
62 > to testing and only the core apps in stable).
63 >
64 >
65 >
66 >