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

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

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?

> 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.

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.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]