Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@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 08:20:04
Message-Id: 1504685997.21081.2.camel@gentoo.org
In Reply to: Re: [gentoo-project] call for agenda items -- council meeting 2017-09-10 by Matt Turner
1 W dniu wto, 05.09.2017 o godzinie 16∶28 -0700, użytkownik Matt Turner
2 napisał:
3 > On Tue, Sep 5, 2017 at 2:09 PM, Aaron Bauman <bman@g.o> wrote:
4 > > On Tuesday, September 5, 2017 4:54:35 PM EDT Matt Turner wrote:
5 > > > On Mon, Sep 4, 2017 at 10:22 AM, David Seifert <soap@g.o> wrote:
6 > > > > Hi William,
7 > > > >
8 > > > > given the massive inactivity of the sparc and hppa arches, I would like
9 > > > > to request dropping their profiles to 'dev'. I would like two votes:
10 > > > >
11 > > > > 1) Should sparc be dropped to a 'dev' profile?
12 > > > >
13 > > > > 2) Should hppa be dropped to a 'dev' profile?
14 > > > >
15 > > > > I hope this can clear a lot of the STABLEREQ and KEYWORDREQ backlog
16 > > > > that is making maintenance in Gentoo cumbersome.
17 > > >
18 > > > I am against moving these to dev profiles for all the reasons Michał gives.
19 > > >
20 > > > For everyone's information, sparc is in its current state because
21 > > > bender, our sparc development system hosted at OSUOSL died in April
22 > > > and Infra has not fixed it for whatever reason. I have contacted
23 > > > Oracle about donating modern hardware to the Gentoo Foundation and
24 > > > they expressed interest, but nothing concrete has happened yet.
25 > > >
26 > > > Jack Morgan also decided to retire about the same time because of the
27 > > > apparent crusade to drop support for architectures like sparc.
28 > > >
29 > >
30 > > So all we had was one system and a couple of testers on sparc? No one seems
31 > > to have complained others than those folks who were impacted by the lack of
32 > > response and time from sparc.
33 > >
34 > > > As an arch tester, I can tell you that it's horribly boring and
35 > > > tedious work. I'd be happy to drop most keywords to ~arch (and Tobias
36 > > > and I have agreed to do exactly this for alpha). In my experience as a
37 > > > member of the MIPS team I can also tell you that fully ~arch is
38 > > > terrible for stage building -- you're constantly dealing with generic
39 > > > unstable problems and not with anything specific to the architecture
40 > > > or stage building. Dropping profiles to dev/exp only exacerbate this
41 > > > problem.
42 > > >
43 > >
44 > > I don't think alpha is the problem here. Alpha is actually pretty good IIRC.
45 > > Why change anything on alpha?
46 >
47 > For a couple of reasons. Obviously there are not lots of alpha users
48 > these days, so investing lots of time in it is sort of a questionable
49 > choice.
50 >
51 > But also because it's boring as hell. It's zero fun, and it's not
52 > interesting work. I enjoy working on weird architectures and learning
53 > about them, but arch testing is not that. It's busy work, and I'm busy
54 > enough without it :)
55 >
56 > By reducing the set of packages that we have to test and mark stable,
57 > we're left with more time to do the things that we actually find
58 > interesting and focus on the packages that actually matter (the
59 > toolchain, for example).
60 >
61 > > > As such, I suggest that instead we consider dropping everything
62 > > > outside of the @system set (and its dependencies) to ~arch for select
63 > > > architectures. This will ensure that the core system remains stable
64 > > > and stage building goes as smoothly as possible. With the
65 > > > significantly reduced stabilization work load, I suspect that the arch
66 > > > testers can keep up with keyword requests and stabilization requests
67 > > > for @system packages.
68 > > >
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 > > Council definitely needs to be involved. Everytime this conversation has been
73 > > brought up nothing changes. The only thing *sure* to change is the
74 > > involvement of the respective arch testers. It is an almost "strike" like
75 > > mentality when someone debates the relevancy of said architectures.
76 > >
77 > > Letting the broader user base suffer at the behest of a few minor arch teams
78 > > is not useful for anyone.
79 >
80 > I truthfully don't know how anyone is suffering. Having some old
81 > ebuilds in the tree because sparc hasn't stabilized something newer is
82 > not causing suffering in my opinion.
83 >
84
85 ...except that some old ebuilds quickly grow into a huge tree of
86 dependent obsolete packages, eclass logic, deprecated EAPIs, open
87 security vulnerabilities and so on.
88
89 Cleaning up takes a lot of work. If you block cleanups for a few months,
90 we end up with a huge pile of deferred cleanups which someone will have
91 to handle. And it will take much more work than if the cleanups were
92 done timely, and a lot more effort to even recall what needs to be done.
93
94 --
95 Best regards,
96 Michał Górny