Gentoo Archives: gentoo-project

From: William Hubbs <williamh@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] call for agenda items -- council meeting 2017-09-10
Date: Wed, 06 Sep 2017 01:52:04
Message-Id: 20170906015200.GA9115@linux1.home
In Reply to: Re: [gentoo-project] call for agenda items -- council meeting 2017-09-10 by Rich Freeman
1 On Tue, Sep 05, 2017 at 02:18:12PM -0700, Rich Freeman wrote:
2 > On Tue, Sep 5, 2017 at 4:54 PM, Matt Turner <mattst88@g.o> wrote:
3 > >
4 > > For everyone's information, sparc is in its current state because
5 > > bender, our sparc development system hosted at OSUOSL died in April
6 > > and Infra has not fixed it for whatever reason.
7 >
8 > If nobody who uses Gentoo owns a sparc, why are we so concerned about
9 > maintaining the architecture?
10 >
11 > > I'd be happy to drop most keywords to ~arch (and Tobias
12 > > and I have agreed to do exactly this for alpha). In my experience as a
13 > > member of the MIPS team I can also tell you that fully ~arch is
14 > > terrible for stage building -- you're constantly dealing with generic
15 > > unstable problems and not with anything specific to the architecture
16 > > or stage building. Dropping profiles to dev/exp only exacerbate this
17 > > problem.
18 >
19 > Well, then somebody on the sparc project team should just do it. They
20 > don't need anybody's permission to do so.
22 Rich is absolutely correct, the sparc team should just do this if it is
23 what they want to do. ignoring newer stable requests and forcing
24 maintainers to keep old versions of packages in the tree forever is not
25 an option due to security and other reasons.
27 The way I see it, once a version of a package is stable on some arch,
28 the arch team owes it to the maintainers to stabilize newer versions of
29 that package in a timely manor once the maintainer opens a stable
30 request.
32 An arch team is also free to destabilize all versions of any package at
33 any time. If they do that, they are no longer required to stabilize
34 newer versions since the package is not in their stable tree.
36 An arch team can, also without anyone's permission, move their profiles
37 to dev or exp if they choose to do so.
39 Maintainers, on the other hand, do not have any of these options, so if
40 arch teams disappear or fall behind on stabilizations, we are forced to
41 keep old versions of packages in the tree.
43 That is why this keeps coming up. Arch teams aren't keeping up, and they
44 aren't de-stabilizing packages they do not want in their stable tree and
45 thereby reducing their own work load.
47 >
48 > If we don't have a sparc project team, and we don't have anybody who
49 > even owns a sparc, then why are we worried about this in the first
50 > place?
52 Agreed. If there is no sparc project team and no dev owns a sparc, it
53 seems pretty pointless to claim that we support a sparc stable tree.
55 > > As such, I suggest that instead we consider dropping everything
56 > > outside of the @system set (and its dependencies) to ~arch for select
57 > > architectures. This will ensure that the core system remains stable
58 > > and stage building goes as smoothly as possible. With the
59 > > significantly reduced stabilization work load, I suspect that the arch
60 > > testers can keep up with keyword requests and stabilization requests
61 > > for @system packages.
62 >
63 > If the arch testers can't even manage to drop keywords, how are they
64 > going to manage to keep up with stable requests on the @system set?
65 >
67 Another very good question.
69 > > I don't think we need council to be involved in this case. Please have
70 > > a little more patience until this can be done.
71 > >
72 >
73 > Patience for who?
74 >
75 > Who will do this, and when do they plan for it to be done?
76 >
77 > If somebody wrote a post saying, "I realize this is a problem, I'm
78 > taking over as the new sparc lead, give me a week or two to clean up
79 > the keywords and we'll keep up on the rest of the stable requests" I
80 > can't imagine that anybody would be anything but supportive.
82 Like I said above, this issue keeps getting brought to council because
83 arch teams fall behind and disappear rather than trying to reduce their
84 work load using options that are already available to them without
85 involving anyone.
87 Thanks,
89 William


File name MIME type
signature.asc application/pgp-signature