Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Andrew Savchenko]

On Sun, 5 Apr 2015 18:54:10 -0400 Rich Freeman wrote:
> On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@g.o> wrote:
> >
> > 2. Otherwise allow developers to drop stable keywords from affected
> > package and _all_ its reverse dependencies. This way a part of
> > stable tree will be removed, but only a part. With this approach
> > arch teams will be freed of an extra burden, while they will be
> > still able to maintain a smaller stable tree.
> >
> > This is a win-win solution: a stable tree will be still kept in a
> > maintainable size and developers will not have a long-term blockers
> > on their stabilization requests.
> >
> > 3. And last but not the least: apply the rules above to all arches,
> > not just minor teams (though probability that amd64/x86 will be
> > slow is lower, of course).
> >
>
> This was some of what I was getting at.  My question still stands that
> I'm not sure arch teams REALLY want 300 packages to have their stable
> keywords removed instead of just having one package break the
> depgraph.

Hmm, that's a hard question. I tried to consider this issues from a
point of view of a user of such arch. If package is not used or
user may delete it and its deps without much harm, it doesn't affect
user at all. If it is used and needed, then in case of:

- one package with removed stable keyword a user have to add to
package.keywords only a single package, though it might be
difficult to locate such package, because portage deptree failure
events may be really obscure sometimes;

- all subtree of stable keywords is removed; then user have to
add all these packages to package.keywords, portage messages should
be clear here (but one never knows), though manual keywording of
hundred of packages will be irritating at best (even using "cat/*"
masks). So if number of affected installed packages is large, users
will likely move to ~arch all their setup.

So from user's perspective stable deptree broken in single point is
a better solution, but(!) if portage will cleanly suggest this
point.

Another issue to consider: what if we have one such package that
broke stable deptree, then after awhile another one and so on. In
the result stable tree will got corrupted beyond repair.

Maybe some grace period will help here? E.g. remove stable keyword
from a single package, wait for 30 days (or so) for reaction from a
team, and then dekeyword all reverse dependencies.

> I would prefer to get at a more generic policy that can be applied
> everywhere, and not just arch by arch.  Being able to keep up or not
> isn't really a black/white thing.  Or rather, if it is I think it is
> more a case that nobody can keep up.  I think that it would be better
> to have one policy that makes sense on any arch, and as you point out
> it probably won't tend to get applied much to amd64/x86 simply because
> they are better supported.

Agreed, the policy should be generic and for everyone (maybe with
reasonable exceptions as toolchan or other core packages).

Best regards,
Andrew Savchenko