Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Michał Górny]

Dnia 2015-02-16, o godz. 10:37:12
William Hubbs <williamh@g.o> napisał(a):

> On Mon, Feb 16, 2015 at 02:34:50PM +0100, Pacho Ramos wrote:
> > Hello
> >
> > Every day I am hitting tons of blockers stabilizations and keywording
> > requests for alpha, sparc, ia64, ppc and ppc64.
> >
> > Again, I would suggest to either decrease radically the amount of stable
> > packages of some of that arches or even make them testing only.
> >
> > For reducing their stable tree, my suggestion would be to either keep
> > their current stage3 packages stable or stage3+some concrete (and
> > public) list of packages.
> >
> > Currently situation is not good at all as we rely on mostly one member
> > needing to handle most stable work and, if any stablereq has any issue
> > leading to it not being able to be handled in an "automated" way, the
> > bug gets blocked for months. Also, keywording work is mostly stalled on
> > this arches as it's done by even less people.
> >
> > The current policy of maintainers dropping keywords after 90 days is
> > simply not applied because it leads up to that maintainer needing to
> > kill himself that keyword and ALL the reverse deps keywords and, then,
> > all that effort should probably be replaced by making the opposite, I
> > mean, reducing the stable tree of that arches to a minimum and moving
> > all the other packages to testing. The main advantage of this is that it
> > needs maybe more effort in one round but it solves the problem for the
> > future. On the other hand trying to kill keywords of a package *and all
> > its reverse deps* requires a lot of work every time the problem appears.
>
> I think the cleanest way forward would be to mark these arch's dev or
> exp in the profiles. That way, maintainers don't have to worry about
> them and the people maintaining the arch's can determine what needs to
> be stabilized at their own paces.

Sounds like a very bad idea. This will only cause developers to
frequently break the tree accidentally because of no repoman checks
by default.

-- 
Best regards,
Michał Górny