On Tue, Aug 16, 2016 at 08:02:29AM +0000, Duncan wrote: > William Hubbs posted on Mon, 15 Aug 2016 15:01:05 -0500 as excerpted: > > > > > This works unless you are talking about packages in @system. > > I do see core packages on these arches also languish in ~ for months > > with open stable requests. > > > > The only way to handle one of those would be to remove the old version > > and let their deptree break until they catch up. > > If system-core packages are languishing in ~ for months on some archs, > isn't it time for maintainers of those system packages to appeal to > council to regress those archs to experimental and kill their stable > keywords "at will"? A decision like this doesn['t actually have to involve the council. There's nothing stopping an arch team, right now, from changing their profile to dev or exp. Also, from where I sit personally, arch teams can do several things with keywordreqs and stablereqs they don't do usually. For keywordreqs, they could just not keyword the package and say that they don't feel they have enough resources to support it. For stablereqs, they aren't required to stabilize, but if they choose not to stabilize the new version, I feel they should destabilize all older versions as well so that maintainers can remove them. There's not a requirement that arch teams support every package that comes to them, even if they want their profiles to have stable status. If an architecture has stable status, I would say that the @system set and all of its reverse dependencies should be kept stable, but everything else is optional, depending on manpower etc. William