Strict compliance with the handbook would seem to forbid having a stable
package depend on an unstable package, and if you have to downgrade a
dependency and it causes a cascade, I would opine, that, perhaps, the
package in question should not have been stabilized to begin with.

That said, I as a user have noticed that packages tend to stall in
stabilization for awhile.

What about a script that can rank ~arch keyworded packages by some sort of
priority?

Maybe point out which one has the most reverse dependencies?  Or which one
has been stuck in ~arch the longest?  Or some sort of scoring mechanism
that can flag the most urgently needed stabilizations?

Come to think of it, I think debian has a system that flags the most
popular packages.  Does gentoo have a way to note what packages are most
important?

On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ramos <pacho@gentoo.org> wrote:

> El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> > [...]
> > Well, I wasn't suggesting that breaking the depgraph is great.  Just
> > that I think it is better than calling things stable which aren't.
> >
> > A better approach is a script that does the keyword cleanup.
> >
> > So, if you want to reap an ebuild you run "destabilize
> > foo-1.2.ebuild".  It searches the tree for all reverse deps and
> > removes stable keywords from those.  Then you commit all of that in
> > one commit.
> >
> > If you want to be extra nice you stick it in a pull request in github
> > and point it out to the arch team and ask them if they're sure they
> > don't want to stabilize your package...  :)
> >
>
> Well, the reason I was suggesting to allow maintainers to stabilize
> after the 90 days timeout over *current* policy of allowing the
> dekeywording is that the dekeywording is completely unrealistic to do
> as some packages have a huge amount of reverse deps. Even with the
> script (and, well, I would like to see that script existing... because
> we are having this issue for ages, and that is the reason that nobody
> is moving things to testing actively), you will find many many cases of
> packages having so many reverse dependencies that if you try to move it
> to testing it becomes soon a hell.
>
> The main issue is that, once you start dekeywording one package, you
> jump to, for example, dekeywording another 3 reverse deps, then you
> need to continue with the reverse deps of that reverse deps... and at
> the end, it's completely impossible to manage it (I still remember how
> hard was to move to testing most of Gnome... and we even were lucky as
> we were able to do that with the jump to Gnome3).
>
> Then, my point it to allow the maintainer to keep stabilizing it
> *after* the 90 days timeout. If after that time, the arch team is
> unable to even reply, nobody has reported any build/runtime issues
> related with that arch, I would go ahead. Otherwise, it looks pretty
> evident to me that that arch is near to be used by nobody and maybe it
> should be moved completely to testing (or most of their packages moved
> to testing and only the core apps in stable).
>
>
>
>