Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Sun, Sep 15, 2013 at 11:22 AM, Pacho Ramos <pacho@g.o> wrote:
> El dom, 15-09-2013 a las 11:03 -0400, Rich Freeman escribió:
>>
>> So, how about this as a policy:
>> 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.
>>
>> Note that if upstream doesn't support an arch, then it falls to the
>> arch team (and not the maintainer) to support that arch if they want
>> it stable.
>>
> I guess an important problem is that, once we drop keywords in a
> package, a cascade effect can appear. For example, if we drop stable
> keywords of gtk+ and pango due pending keywording, we will need to also
> drop a ton of packages. And for cases where we would need to drop the
> keywording completely, the situation can be even more difficult.

Fully appreciate that.  Given the choice of removing ALL of the stable
keywords, and removing many of the keywords, the latter seems to be a
better choice, at least initially.

However, I do see that as a PITA.  If it becomes a trend, the stable
keywords should be dropped entirely.  Really, it should be the arch
teams themselves that step up and remove their own stable keywords.
For this reason I'm not sure I'd even want to require maintainers to
change any keywords when they remove the last stable version on an
arch - just let the reverse dependencies break and either the arch
team or users will have to clean up the mess (which nobody will see
unless they use that arch).

Ultimately, arch teams need to step up if they want to have stable keywords.

As far as the users go - more need to become developers if they want
to have stable keywords, or pay somebody else to do so on their
behalf.  That's just how things work in a volunteer-based distro.

Rich