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

[Andrew Savchenko]

On Mon, 6 Apr 2015 09:59:22 +0200 Michał Górny wrote:
[...]
> > 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.
>
> Which means developers can't commit properly for 30 days. Really
> awesome solution, thank you. Please ping QA instantly once you do it,
> you'll save us time figuring who to ban for the breakage.

I sad nowhere I'm going to do it. We are discussing opportunities
to fix current sore situation. Threatening people with bans just
for their thoughts reminds me of George Orwell's Thought Police...

> Let me remind you: once you break dependency tree on *ANY* stable
> architecture, repoman won't let you commit. Travis turns red. All pull
> requests are marked as broken.

Repoman, travis and other QA tools can be fixed if policy changes.
That's not a problem. Right now we have an all-green travis, but
outdated, broken and likely insecure packages it tree marked as
stable. That is the problem we're trying to discuss here.

And as I see this problem has no good solution, so one less painful
for users should be chosen. If this will require a QA policy
update, then it should be done.

Best regards,
Andrew Savchenko