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

[Rich Freeman <rich@thefreemanclan.net>]

On Fri, Apr 3, 2015 at 3:33 PM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 03/04/15 01:14, Tim Harder wrote:
>> The next council meeting will be on April 14th, 19:00 UTC in
>> #gentoo-council on Freenode.
>>
>> Please respond to this message on the gentoo-project list with any
>> agenda items you want to propose or discuss.
>>
>> Thanks,
>> Tim
>>
>
> Could we please revisit lagging arch teams again? Specifically, I'd like
> to see the package-by-package proposal extended to other minor archs
> including ppc and ppc64.
>

If we're going to bring this up, is sparc a concern for anybody?  I
mention it only because it was brought up last time, not because I
have any specific reason to have concerns with them.  If we're going
to discuss this again, we might as well be holistic.

For that matter, part of me wonders if this should really be a "minor
arch" policy vs just being general policy, and perhaps we should even
consider doing the same thing with x86/amd64.  If for some reason
upstream doesn't support one of those archs or there are no major
issues with moving to the new version, why shouldn't we require arch
teams to stabilize within 90 days even for the big ones?

For reference, the policy we came up with last time for ia64 and alpha only was:

  "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
  pending STABLEREQ, for 90 days with archs CCed and otherwise ready
  to be stabilized, the maintainer can remove older stable versions of
  the package at their discretion. A package is considered ready to be
  stabilized if it has been in the tree for 30 days, and has no known
  major flaws on arches that upstream considers supported."

The "arches that upstream considers supported" bit seems to make this
fairly suitable for anybody.  The intent is to follow upstream, and if
we want to do more then that is on the arch team to make happen unless
the maintainer is willing to do it.

-- 
Rich