Re: [gentoo-dev] Re: Stabilisation procedure

[Kent Fredric]

On Fri, 18 Nov 2016 00:13:35 +1100
Michael Palimaka <kensington@g.o> wrote:

> What is the *real* risk that kde-apps/kcalc builds against stable
> dev-libs/gmp but then starts producing funny numbers at runtime?
>
> Let's put it another way - assume we're stabilising a new version of
> dev-libs/gmp instead. Should we test already-stable kde-apps/kcalc
> first? What about the other hundred reverse dependencies?
>
> Just to be clear, I'm not advocating banning runtime testing. I just
> think that, considering the state of the stable tree, we should consider
> very careful in which situations we actually gain value from it. That's
> for another thread, however. I deliberately worded the document so that
> the final decision on the exact level of testing required (runtime or
> otherwise) is between the person filing the stabilisation request and
> the person actioning it.

This IME rather depends on the nature of the package in question, and the
general nature of its dependencies.

Usually you can make the conjecture that only direct dependents of
each other can affect each other via changes.

But spooky-action-at-a-distance can also happen, where in 

   a -> b -> c

C changes
B is unaffected
A is broken

Though it makes more sense to not have a blanket "recusively check dependents"
policy, and perhaps either have a "Test these things when I change" list,
or an inverse "Test me when X changes" list.

The latter of these is not entirely unlike the need to add new := slotdeps
for things that didn't need to depend on Perl, but needed to be rebuilt when perl is.

(Except s/rebuilt/retest/ )