[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] New Working Group established to evaluate the stable tree
From:       Pacho Ramos <pacho () gentoo ! org>
Date:       2016-08-17 8:50:26
Message-ID: 1471423826.31785.52.camel () gentoo ! org
[Download RAW message or body]

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).



[prev in list] [next in list] [prev in thread] [next in thread]