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

[Rich Freeman]

On Wed, Apr 8, 2015 at 1:39 PM, William Hubbs <williamh@g.o> wrote:
> On Wed, Apr 08, 2015 at 09:33:39AM -0400, Rich Freeman wrote:
>> Well, we really have a few options as far as imposing changes from
>> outside the arch team goes (the arch team can clean up its own
>> depgraph, of course, but presumably we'd be taking action only if they
>> didn't).
>>
>> 1.  We could make the arches dev/exp as you point out, and then allow
>> maintainers to just drop stable versions and break their depgraph.
>>
>> 2.  We could keep the arches as stable, but then allow maintainers to
>> do massive keyword changes when they drop otherwise-stable versions.
>> That wouldn't break the depgraph, but it would mean that at random
>> times huge numbers of packages could have their keywords change.
>
>  It seems like the only difference between these two options would be
>  who is responsible for fixing the depgraph. Let me say why I'm thinking
>  this.
>
> Suppose that foo-1 is stable everywhere and I'm looking at a stable
> request for foo-2. I'm passed 90 days since I assigned the arch teams to
> this stable request. Also, foo is unslotted.
>
> Removing foo-1, or moving it back to ~arch, is going to have the same affect
> for all arches where it was stable and foo-2 is not, so I'm thinking I
> may as well remove foo-1.
>
> The difference, for stable vs non-stable arches, is that I will get
> complaints from repoman when I remove foo-1 for stable arches and I
> should also fix those.
>
>  Is this right?

No.  In neither option would you move foo-1 to ~arch.  In neither
option would you get repoman complaints.

In option 1 you would delete foo-1.  Users of the arch will start
getting errors when they try to do updates, since foo-2 is keyword
masked.  Users could just accept ~arch for foo-2 to fix this most
likely, though it may not work in some cases.  The arch team can clean
up the depgraph at some point as well.  You don't ever get repoman
complaints because the arch is set to dev/exp, and is ignored by
repoman.

In option 2 you would STILL delete foo-1, and you would also change
all of its reverse dependencies to ~arch as well.  Users of the arch
would get errors when they try to do updates, since many packages they
have installed are now keyword masked, and foo-2 is also keyword
masked.  Users would have to accept ~arch for all those packages to
restore normal operation.  Later the arch maintainers could restore
the depgraph to what it was before while stabilizing foo-2, which
involves fixing many packages potentially, and even if it all ends up
as stable again users have tons of cruft in their config files.  You
don't ever get repoman complaints because the depgraph was always
consistent.


>
>> Neither option is really ideal.  I think that #1 is the lesser evil,
>> but that does mean that we need to make a distro-wide decision.  The
>> advantage of #2 is that it basically is a NOP unless the arch team
>> actually reaches 90 days old.  I think it is better to just have the
>> Council make a decision rather than kicking the can, but that said if
>> an arch team is willing to state clearly that they intend to
>> proactively clean up their depgraph and that they want to keep stable
>> keywords, I'm fine with checking back in a month rather than
>> de-stabilizing them next week.
>
> Option #2 really isn't a NOP. It would say that maintainers have
> permission to remove old stable versions of a package when arch teams
> take more than 90 days to respond to a stable request for a newer
> version of the package.
>

Option #2 is a NOP in the sense that the Council doesn't have to do
anything that has an immediate effect.  Basically we'd just be
deputizing every maintainer out there to purge keywords on any arch in
the list we approve anytime it gets out of hand.  So, if an arch has
no STABLEREQs older than 90 days today, nothing happens today, but if
in six months a glibc STABLEREQ is ignored for 91 days the maintainers
can go ahead and remove every single stable keyword on the arch (to
pick an extreme example).

> Also, do we have to make a distro-wide decision about whether an arch is
> stable? I realize we have been the ones making those decisions, but I
> don't think there is a policy that requires us to.

The only thing we're required to do as a matter of policy is to show
up for a meeting and bang the gavel twice.

I don't really like just kicking the can down the street though.  If
an arch really thinks an extra 30 days will let them become proactive
about trimming their keywords I don't mind giving an extension, but I
really don't want to end this Council term with maintainers
complaining about aging STABLEREQ bugs that they are powerless to do
anything about, and I don't think having random maintainers basically
treecleaning arches is a great solution either even if it lets us
point fingers.

I don't see this as picking favorites - x86 is more important than
sparc or whatever.  All we're doing is just assessing whether an arch
team is able to proactively manage their stable keywords or not.  If
an arch has only a single package marked stable, and they keep up with
just that one package, then they can stay stable in repoman.  If an
arch isn't doing that, then users deserve to know this and understand
the implications.  It means that at any time stuff that is marked as
stable could stop being stable, or could be really out of date.  It
means that they need to be more careful about the weight they give to
a stable keyword.  I just see this as being about truth in
advertising.

Stable keywords are a bit like a contract between package maintainers
and arch maintainers.  The package maintainers agree to maintain
things in a way that keeps the stable experience stable.  The arch
maintainers agree that in exchange they will keep up with stable
requests so that package maintainers aren't dealing with cruft.  When
the package maintainer violates their end of the deal, QA descends on
them.  When the arch maintainers violate their end of the deal, the
Council marks their arch non-stable.  This is a reversible decision.
Arch maintainers can control the size of their commitment by not
keywording things as stable in the first place, and removing stable
keywords when they can't keep up.

-- 
Rich