[gentoo-dev] Re: About reducing or even removing stable tree for some arches

[Duncan]

Pacho Ramos posted on Mon, 16 Feb 2015 14:34:50 +0100 as excerpted:

> The current policy of maintainers dropping keywords after 90 days is
> simply not applied because it leads up to that maintainer needing to
> kill himself that keyword and ALL the reverse deps keywords and, then,
> all that effort should probably be replaced by making the opposite, I
> mean, reducing the stable tree of that arches to a minimum and moving
> all the other packages to testing. The main advantage of this is that it
> needs maybe more effort in one round but it solves the problem for the
> future. On the other hand trying to kill keywords of a package *and all
> its reverse deps* requires a lot of work every time the problem appears.

Perhaps my non-dev status prevents me from understanding the difficulty 
here, but...  I really don't see the problem.

1) I don't believe the 90-day policy was /supposed/ to be particularly 
easy.  It was supposed to be a pressure relief valve, to release pressure 
only if it built up beyond a certain level, such that both archs and 
package-devs could still live with the situation by keeping the pressure 
from going off the scale at either location.

As a pressure reliever, what you defined as a bug I'd rather define as a 
feature.  If the situation gets bad enough and the pressure high enough, 
there's an approved method to relieve it, but that method itself isn't 
entirely pain-free, so it doesn't tend to be used until the pain of not 
using it is worse than the pain of using it, which, I'd argue, is 
functioning as intended.

2) The very requirement of having to kill ALL the reverse-deps seems to 
me to already lessen the pressure necessary to tip the balance the next 
time, since either it's not the problem its made out to be if it's only a 
handful of packages, or within a few cycles of doing this, there will be 
dramatically fewer packages keyworded in the first place to worry about, 
and thus dramatically fewer packages to have to dekeyword this time 
around.

Yes, the first time's going to be hell.  And the second time could easily 
be 90-95% as bad, particularly if the two packages are in separate areas 
and there's little overlap.  But the tenth?  By then, the number of 
packages still keyworded in the first place should be down enough to make 
a difference.  And the 20th?  By then, things should be much more 
reasonable.


So you're suggesting a flag day and volunteering to do most of the work.  
I won't argue with that as I don't have a dog in this fight.  But it 
seems to me, by the time you do even say five existing 90-day-
dekeywording-policy actions, you'll either have something already looking 
a lot more like the goal you outline above than the current state and 
will be well on your way, or if that DIDN'T dekeyword enough packages to 
already be easier, then by definition there's only a handful of such 
dependencies in the first place.

Either way, I simply don't see the problem, certainly so when comparing 
the work of just doing it under the existing policy, to fighting the 
political war necessary to change it -- and even assuming a win, ending 
up dekeywording pretty much the same set of packages as you'd have done 
with a few rounds under the existing policy anyway.

Again, not that I disagree.  As I said, no dog in this fight and I might 
actually benefit by the developer time then freed up to work on fights I 
do have a dog in.  But I expect this question will come up in some form 
in any case, and by answering it now, it'll already be dealt with.

Plus, I'm simply curious, as there's evidently an angle I'm blind to, and 
now being aware of that blindness, it's disturbing enough to me that I 
want to be rid of it, thus the question. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman