Re: [gentoo-dev] games.eclass

[Rich Freeman <rich0@gentoo.org>]

On Fri, Aug 21, 2015 at 2:17 PM, hasufell <hasufell@gentoo.org> wrote:
>
> I don't know. Stick to your word, maybe?

I'm glad we have you here to be our conscience.  :)

I'm sure this will go on the next agenda.  However, the decision to
kick the can was actually an intentional one.  We were hoping to see
more interest in fixing the games team and it didn't turn up.  We
didn't want to cause more harm than good.

>
> So far, neither the council, nor QA, nor ComRel were particularly
> helpful with the situation.

Well, the problem is that nobody wants to clean up games.  Short of
the council members joining the games team and doing the work
themselves there isn't really anything that is going to make you
happy.  Another solution is to just treeclean all the games, and that
certainly isn't going to make anybody happy.

We get it.  Everybody wants somebody else to spend a lot of time doing
something that will make their life easier for free.  It is a pretty
common theme in FOSS.  Certainly we're not the only distro where I've
seen this sort of complaint come up.

I think we try to find a good balance in Gentoo in empowering devs and
still providing most of the benefits of centralization to users and
each other.

>
> If the team is disbanded, then regular tree policy applies and
> everything goes through the regular community discussion/decision
> channels without the need of QA putting their prefixes/hats everywhere.

So far the QA team hasn't done anything at all on this issue.  In fact
the QA lead suggested that he didn't want to take the initiative.
Perhaps you should wait for QA to actually do something before you
appeal it to the council, and wait for the council to deny your appeal
before you complain about it here.

And QA doesn't just govern packages maintained by project teams.  In
fact, those are the sorts of packages they /should/ have to spend the
least time worrying about.  Of course, they're free to pursue policy
violations wherever they see them.

In any case, I don't find the whole argument about "who has permission
to implement this really good idea" debate very helpful.  I'd rather
focus on whether it is a really good idea.  If it is, let's make it
happen.

I don't want to turn into Debian where after it is clear that most
people want something to happen they go back and forth for six months
with 14 resolutions and 12 committees and 85 appeals to parliamentary
procedure all arguing over who has the power to do what.  Heaven
forbid that there are two developers somewhere who are forced to do
something without as much due process as the US government affords
people accused of murder.  This isn't the US Senate.  If devs ever
want that kind of operation, do me a favor and elect somebody else to
Council.

This is just a discussion right now.  I think most of the arguments
pro and con have been made, and if there are others people can make
them.

I just don't think it is helpful to argue about who is allowed to
raise the topic in the first place, or who is allowed to make the
decision.  QA has fairly broad discretion in our current setup, and
the Council has jurisdiction over just about anything that isn't
financial/legal in nature.  Heck, some have argued for having a
project leader / dictator role to cut through red tape.  We don't need
to argue about whether we're allowed to make progress.

>
> If a new team is constituted, then they might establish new policies,
> also without QA dictating anything. And I would give that some time,
> which means don't start funny mass commits/conversions.
>

Well, that "new team" has had months since they failed to resolve the
last crisis, and it has weeks before the next council meeting.  If the
"new team" hasn't even gotten around to acting like they actually
exist by then, I wouldn't expect everybody else to hold their breath.

-- 
Rich