Re: Re: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12

[Rich Freeman <rich0@gentoo.org>]

On Wed, Jul 30, 2014 at 2:15 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>> I didn't bother replying before because I think my assumption was that
>> the council was clever enough to recognize silly when they saw it.
>> There never was a compelling argument for dispelling policy set by
>> groups in the general case and I'm not sure why the games group would
>> be considered to have lesser status in that regard.
>
> That actually doesn't address any of the issues brought up.
>
> The main question is, why should the games team have more status than other
> projects?

++

Generally I am in favor of giving projects that adhere to GLEP39 more
of a say in things than individual maintainers, but setting aside
QA/Comrel/Infra there aren't really any projects out there which claim
the same kind of scope as games.  Amd64 might have a say over your
KEYWORDS, or systemd might want to install a text file you don't have
to look at, but none of them are going to basically rewrite your
ebuild, rename it, or tell you to get it out of the tree.  The
Gnome/KDE projects don't care if you install an application that uses
libkde/etc, though you'd do well to coordinate if you don't want
random breakage on the next big change.

If this were just an issue about games not accepting new members I
think that would be pretty trivial to fix, but I haven't gotten any
replies to my solicitation.  So, this is more than whether the lead
responds to member requests.

Some options open to the council are:
1.  Let the games project keep its policy, and anybody who wants to
change this has to join the project and call for elections (the
council can shoe-horn members onto the project if necessary).
2.  Directly tweak games policy but preserve the project and its
scope.  So, games would still have to adhere to games project policy,
but the Council might change specific policies (use of eclass, group,
etc).
3.  Restrict the games project scope, such as giving it authority if
the package maintainer elects to put it in the games herd.
4.  Do nothing.

I think #1 is the least intrusive (besides #4), but since nobody
responded to my call for new members I don't know that it will
accomplish anything.  I don't really care for #2 - it seems the most
meddlesome and I'm not sure what would be left for the project to
actually do if we basically ripped out all their policies and told
them they can't change them.

Do we really have a sense for how much demand there is for change?  #4
(or something equivalent like nicely asking games to deal with this)
might make sense if we think this is really just 2-3 devs with an
opinion, and that there isn't a larger demand out there.

However, right now #3 is where I'm somewhat leaning personally.  I
think it would be helpful if more members of the community with a
strong opinion speak up.  Apologies to the games project if it seems
like we're demanding a performance, but in the end the Council is as
much bottom-up as top-down and if all we hear is people demanding a
change, it is a bit hard to just ignore it, and really, listening to
the community is everybody's job anyway.

Rich