Re: [gentoo-project] call for agenda items -- council meeting 2017-09-10

[William Hubbs]

On Tue, Sep 05, 2017 at 02:18:12PM -0700, Rich Freeman wrote:
> On Tue, Sep 5, 2017 at 4:54 PM, Matt Turner <mattst88@g.o> wrote:
> >
> > For everyone's information, sparc is in its current state because
> > bender, our sparc development system hosted at OSUOSL died in April
> > and Infra has not fixed it for whatever reason.
>
> If nobody who uses Gentoo owns a sparc, why are we so concerned about
> maintaining the architecture?
>
> > I'd be happy to drop most keywords to ~arch (and Tobias
> > and I have agreed to do exactly this for alpha). In my experience as a
> > member of the MIPS team I can also tell you that fully ~arch is
> > terrible for stage building -- you're constantly dealing with generic
> > unstable problems and not with anything specific to the architecture
> > or stage building. Dropping profiles to dev/exp only exacerbate this
> > problem.
>
> Well, then somebody on the sparc project team should just do it.  They
> don't need anybody's permission to do so.

Rich is absolutely correct, the sparc team should just do this if it is
what they want to do. ignoring newer stable requests and forcing
maintainers to keep old versions of packages in the tree forever is not
an option due to security and other reasons.

The way I see it, once a version of a package is stable on some arch,
the arch team owes it to the maintainers to stabilize newer versions of
that package in a timely manor once the maintainer opens a stable
request.

An arch team is also free to destabilize all versions of any package at
any time. If they do that, they are no longer required to stabilize
newer versions since the package is not in their stable tree.

An arch team can, also without anyone's permission, move their profiles
to dev or exp if they choose to do so.

Maintainers, on the other hand, do not have any of these options, so if
arch teams disappear or fall behind on stabilizations, we are forced to
keep old versions of packages in the tree.

That is why this keeps coming up. Arch teams aren't keeping up, and they
aren't de-stabilizing packages they do not want in their stable tree and
thereby reducing their own work load.

>
> If we don't have a sparc project team, and we don't have anybody who
> even owns a sparc, then why are we worried about this in the first
> place?
 
Agreed. If there is no sparc project team and no dev owns a sparc, it
seems pretty pointless to claim that we support a sparc stable tree.

> > As such, I suggest that instead we consider dropping everything
> > outside of the @system set (and its dependencies) to ~arch for select
> > architectures. This will ensure that the core system remains stable
> > and stage building goes as smoothly as possible. With the
> > significantly reduced stabilization work load, I suspect that the arch
> > testers can keep up with keyword requests and stabilization requests
> > for @system packages.
>
> If the arch testers can't even manage to drop keywords, how are they
> going to manage to keep up with stable requests on the @system set?
>

Another very good question.

> > I don't think we need council to be involved in this case. Please have
> > a little more patience until this can be done.
> >
>
> Patience for who?
>
> Who will do this, and when do they plan for it to be done?
>
> If somebody wrote a post saying, "I realize this is a problem, I'm
> taking over as the new sparc lead, give me a week or two to clean up
> the keywords and we'll keep up on the rest of the stable requests" I
> can't imagine that anybody would be anything but supportive.

Like I said above, this issue keeps getting brought to council because
arch teams fall behind and disappear rather than trying to reduce their
work load using options that are already available to them without
involving anyone.

Thanks,

William