Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Rich Freeman]

On Wed, Aug 17, 2016 at 4:50 AM, Pacho Ramos <pacho@g.o> 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.
>

I'm not sure I agree.  If it is scripted, then isn't it just a few
more cpu cycles?

Sure, I get that de-stabilizing one package could trigger
de-stabilizing 200 others, but the list is finite, and the algorithm
is reasonably straightforward.  Just use the portage API and you can
find all the reverse deps for any package, using the same logic
portage will use.  Granted, I could see it getting a little tricky
because you might be de-keywording multiple versions at once, and
those impact multiple versions at once, and you need to trace all of
those, preferably pruning the search space for duplicates as you go.
It actually sounds a little like my iterative map-reduce I used to
compare the git and cvs trees (map expands the dep tree by one level
from all the known impacted packages, reduce prunes duplicates, then
repeat until you've found all the leaves, probably by storing a tag in
the parent record when you've mapped it and found no children so that
future maps skip it).

But, I won't disagree that somebody has to write it.

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

Why even have a stable keyword?  What does it even mean if everything
gets stabilized in 90 days whether it is tested or not, or whether it
even builds?

Take the degenerate case.  Suppose an arch team is completely AWOL.
If we go with my route and de-stabilize packages then you end up with
an arch that is de-facto experimental with no stable packages (or
maybe @system only) after some period of time.  If we instead
stabilize anything after 90 days if there is no response then the AWOL
arch team ends up having more stable packages than any other arch,
because they're the only ones not reporting bugs.

The whole point of a stable branch is that it is curated.  It is
supposed to "just work."  If changes make it in without any testing,
then it loses that quality, and it just becomes a stale testing
branch.  I'd rather have stable be @system only so that you always
have a system that at-least boots and then go from there, or maybe
leave it to individual projects to maintain their own stable branches
with their own QA, than have stuff just dumped in stable without even
a build test, let alone some kind of runtime testing.

I'd even buy that maybe we don't need stable (though I think that the
minor arches are where it is most needed, at least for @system so that
users can actually boot their stage3s).  However, it makes no sense to
go to the trouble to have a stable branch and not do anything to
ensure it is actually stable.

-- 
Rich