Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

On Tue, Apr 07, 2015 at 07:29:31PM -0400, Rich Freeman wrote:
> On Tue, Apr 7, 2015 at 7:25 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> > On 04/07/15 11:38, Michael Palimaka wrote:
> >>
> >> On 07/04/15 08:22, Matt Turner wrote:
> >>>
> >>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> >>>>
> >>>> For instance, in this topic I haven't seen any comment from
> >>>> alpha/ia64/sparc arch teams...
> >>>
> >>> I haven't commented because I don't honestly believe people care.
> >>>
> >>> I'm really disappointed that the discussion is entirely about creating
> >>> keyword-dropping policies and no one is asking whether there are
> >>> things we can do to make keyword/stable requests a more streamlined
> >>> process. But, that kind of thing seems to be par for the course on
> >>> this list.
> >>
> >> We've heard very little from arch teams at all, let alone proposals for
> >> improving the stabilisation process. That's the main reason this sort of
> >> topic keeps coming up.
> >
> > I don't want my silence to be misinterpreted regarding ppc and ppc64.  For
> > those arches, I'm willing to trim back on stabilization, but I really don't
> > want to drop to ~ as we did for mips.  In fact, I'm thinking of turning mips
> > itself back into a stable arches with just the @system packages being
> > candidates for stabilization.  The reason I like this approach is when I
> > build stage3's I can control what I know will build (stable packages) vs the
> > latest packages added to the tree (~arch).  Nothing is more painful than
> > have to manually intervene in a bunch of catalyst builds.  Being able to
> > control what will be built via stable keywords saves time and effort.
> >
> 
> Would you be willing to monitor stablereqs and for ones that you can't
> keep up with, go ahead and remove stable keywords proactively on your
> own?  The main concern is that this is a lot of hassle for
> maintainers.  If the arch team can keep up with maintainers either by
> stabilizing packages or unstabilizing them, I think that will satisfy
> everybody.
> 
> Alternatively, we can just change the status of the arch in repoman.
> Then you can keep your stable keywords if you wish, but package
> maintainers can also break your stable depgraph.

Changing the status of the arches in repoman is all I thought we were
discussing. I wasn't saying we should revert or remove stable keywords
for them. I think that's what vapier is doing with s390, sh, etc.

Marking the arches dev or exp in the profiles means that repoman, by
default, doesn't complain about broken depgraphs for them.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]