Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Rich Freeman]

On Thu, Jun 30, 2016 at 7:19 PM, Daniel Campbell <zlg@g.o> wrote:
> Our ebuilds are maintained by developers, with the occasional
> proxy-maintainer or contributor. Your previous statement combined with
> this amounts to "QA owns and manages the Gentoo repository." You just
> said teams have no autonomy over their own ebuilds, which naturally
> extends to individual developers lacking autonomy for their ebuilds, as
> well.

QA has authority over the Gentoo repository, but their scope for
exercising this authority is relatively narrow.  Ultimately we expect
them to police themselves, but if they become a problem any developer
can appeal to the Council.  For the most part the policies they
enforce have either been the sorts of things almost anybody would
agree with, or they're Council decisions.

If the Council decides on a policy, then QA is completely within their
rights to take action to enforce that policy.  If somebody wants to
appeal they can, but of course they're going to be appealing to the
Council that set the policy.  That is by design.  The whole point of
the Council is to have some way to reach a "final" decision when there
isn't consensus.  Of course, Councils can change their mind, but in
practice this has been rare.

> But ripping out the
> eclass is a "solution" that creates more problems than it solves.

Trust me, this wasn't something the Council undertook lightly.


>
> I expect to be told that use case is poor or irrelevant. Who decides
> which use cases are valid and what qualifies them to make those claims?

Ultimately the Council, by sole virtue of election.  It isn't perfect,
but it is a process that has a form of accountability and it at least
is capable of yielding a final decision.  On a lot of issues either A
or B is better than endlessly bickering between them.  Of course, the
Gentoo way is to support choice and if somebody comes up with a good
way to push the decision into the hands of the end user then we can
just argue over the most sane default.  No matter how you slice it,
there will always be decisions that people disagree over.

Personally, I don't really buy into the SSD use case.  It isn't that I
don't agree with the virtues of SSDs, but the most straightforward
solution to this is to stick / and /usr on the SSD so that all
applications benefit from this.  An entire Gentoo install is only a
few GB worth of binaries/libraries/etc and it is probably a lot more
straightforward to indiscriminately put these on the SSD than to pick
and choose.  Plus, your system will boot a LOT faster.  This is what I
do - basically / is on an SSD and then I mount stuff on top from hard
drives when I need space.

In an earlier email you mentioned that this wasn't a big concern for
you personally but you were concerned for our end users.  One bit of
advice that I'll offer is that if this is the case, let them speak for
themselves.  Speaking personally, I'm interested in feedback from
anybody I get it from.  However, when somebody comes to the Council
with an argument like "somebody, somewhere, might disagree" and nobody
is actually saying "this affects me" then it probably won't get a lot
of weight.

Ultimately, though, you're going to have to trust the judgment of the
council.  Or, whether you trust it or not, you will ultimately have to
abide by it for anything you do using your commit access.

> And how is a QA group taken seriously if they don't address breakage
> that they introduce? Is QA not held to a standard at all? Is it a set of
> arbitrary rules laid down from this separate project that nobody else
> can examine or call for re-examination?

QA is enforcing a Council policy.  Whether something is considered
breakage ultimately is up to the Council.  Who is on the Council is of
course up to all of us.  While I don't advise turning an election into
a referendum on one particular decision I certainly encourage
developers to be selecting Council members based upon their ability to
strike an appropriate balance here.  The Council's ability to dictate
tree-wide policies like these are probably the area where it has the
biggest impact on developers being able to scratch their itches.  So,
this stuff is really important.

The Council also confirms the lead of QA.  And of course there is the
ability to appeal.  There are of course issues with any human-run
organization but I struggle to think of conflicts the QA team has had
with developers which weren't addressed by the QA lead or the team.
Certainly I don't recall actually getting any actual appeals (for QA,
and in my time on the Council I've only seen one Comrel appeal).  I
don't want to get into Comrel but the principle is the same with that
organization, just with a different scope of operations.

> This games.eclass decision breaks use cases, supplies no replacement or
> forward-facing route for users, and is being swept under the rug as
> quickly as possible.

There is no intent to stifle discussion.  You're welcome to state your
opinion.  The Council can always reverse the decision, or the next
Council can do so.  I personally consider either unlikely, but Gentoo
is never compelled to jump off a cliff because of a past mistake.
However, at this point this is a fairly established decision, so while
you can discuss, this isn't considered something on-hold for debate.
That could change if a majority of the Council decides to issue a
stay/etc, but certainly I'm not calling for one based on what I've
heard so far.

Ultimately I feel one of the key purposes of the Council is to remove
obstacles to progress by making calls when they need to be made.  A
call has been made, and there cannot be obstacles for those
implementing the decision.

> Those are weasel words. It was QA's decision to bring the topic to the
> Council, was it not? And it had a vested interest in a favorable ruling
> by the Council, no? If the answer to both is "yes", then QA was just as
> responsible bringing the decision to fruition as the council itself. The
> council doesn't make decisions on its own based on what I've read; they
> make decisions when options or challenges are brought to them.
> Therefore, people who make the most noise get heard and from the looks
> of it, their way as well.

The Council is not bound to the options presented to it, and Council
members can propose Council agenda items the same as anybody else
(we're developers too!).  Speaking personally I certainly try to think
of our developers and users as a whole, and I'm confident my peers
tend to do so as well.  We don't always agree, but I've never had
occasion to question anybody's motives.

Sure, we're more likely to take up a topic that somebody is
complaining about than one that nobody is complaining about.  And of
course we're going to tend to judge dissatisfaction by opposition.
However, we don't pull up the 100-email debate and count the number of
posts on each side.  Ultimately we're going to tend to use our
judgment, which is what we're supposed to be selected for (and really,
what else can we do?).  Persuasive arguments will of course tend to
persuade, but this shouldn't be viewed as a bug.

In this case I can assure you that people were frustrated that it took
as long as it did to end up with a decision, and it largely was
because we recognized the controversy.  There were multiple rounds of
meetings and numerous opportunities to provide feedback.  Ultimately,
however, providing feedback does not guarantee any particular result.

> In short, QA pushed the decision onto the council, the council ruled in
> favor of QA, so now QA gets to deal with the fallout of their decision.
> If the QA team doesn't want that, perhaps they should handle breaking
> changes better. Or elect better leadership.

QA isn't forcing anybody to do anything.  They put out a call for
help.  People can choose to answer it or not at their discretion.  The
Council didn't attempt to force anybody to do anything for precisely
the reasons you state.  We made a decision to clear the way, but
ultimately the people that are most bothered by the eclass will
probably be the ones to implement the decisions.  As long as nobody
interferes with them, it can take however long it needs to take.

FOSS ultimately comes down to "patches welcome."  If it bothers you
that much, go fix it.  The Council can get the roadblocks out of your
way, but the ultimate test of your resolve is whether you're willing
to put in the work.  Anybody can put out an appeal for volunteers.  I
know some have complained that removing the games eclass has taken as
long as it has, and ultimately it comes down to willingness to put in
the work.  If the eclass doesn't bother you, then by all means sit
back and let others take care of it.

-- 
Rich