Gentoo Archives: gentoo-dev

From: William Hubbs <williamh@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: New Working Group established to evaluate the stable tree
Date: Tue, 16 Aug 2016 13:52:54
In Reply to: [gentoo-dev] Re: New Working Group established to evaluate the stable tree by Duncan <>
1 On Tue, Aug 16, 2016 at 08:02:29AM +0000, Duncan wrote:
2 > William Hubbs posted on Mon, 15 Aug 2016 15:01:05 -0500 as excerpted:
3 >
4 > >
5 > > This works unless you are talking about packages in @system.
6 > > I do see core packages on these arches also languish in ~ for months
7 > > with open stable requests.
8 > >
9 > > The only way to handle one of those would be to remove the old version
10 > > and let their deptree break until they catch up.
11 >
12 > If system-core packages are languishing in ~ for months on some archs,
13 > isn't it time for maintainers of those system packages to appeal to
14 > council to regress those archs to experimental and kill their stable
15 > keywords "at will"?
17 A decision like this doesn['t actually have to involve the council.
18 There's nothing stopping an arch team, right now, from changing their
19 profile to dev or exp. Also, from where I sit personally, arch teams can
20 do several things with keywordreqs and stablereqs they don't do usually.
22 For keywordreqs, they could just not keyword the package and say that
23 they don't feel they have enough resources to support it.
25 For stablereqs, they aren't required to stabilize, but if they choose
26 not to stabilize the new version, I feel they should destabilize all
27 older versions as well so that maintainers can remove them.
29 There's not a requirement that arch teams support every package that
30 comes to them, even if they want their profiles to have stable status.
32 If an architecture has stable status, I would say that the @system set and all
33 of its reverse dependencies should be kept stable, but everything else is
34 optional, depending on manpower etc.
36 William


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