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

[Rich Freeman]

On Fri, Jul 1, 2016 at 5:10 AM, Daniel Campbell <zlg@g.o> wrote:
>
> I'm not sure the SSD-for-games-only is the most effective solution
> either, but there are plenty of use cases that I disagree with that tend
> to get by without issue. Are / or /usr on SSD the proposed solution for
> someone who's aiming for the speed boost?
>

Well, that's certainly what I would do.  But, you can ask the games
team if they have a better idea, or feel free to join it.

>
> How are we certain that users will speak up for their cause when it's
> lacking support? Don't we risk alienating people without considering use
> cases?

I specifically said that the Council is NOT limited to considering
only the use cases that come up in the discussion.

Obviously we consider every use case that people suggest or that we
think up.  We probably don't consider use cases that nobody has come
up with.

In any case, if you come up with a good reason not to move forward
with the decision and the Council agrees with you, I'm sure the
decision would be changed.

The fact is that ANY decision can turn out to be a bad one in
retrospect.  That isn't a reason to never make a decision.  If you can
think of a good reason why we're wrong, I'm sure we're going to be
interested (or more likely the next Council will be).  However,
decisions that were made months ago after lengthy discussion don't get
on hold because somebody /might/ come up with another argument (so far
you've only advanced the SSD concern, and I don't see anybody biting
on that one).

> I understand where you're coming from wrt council decisions. I've
> corrected that and started a thread on gentoo-user that will give us
> some insight to how many users' use cases were affected by this decision
> and which use cases they were. Then we can either set a goal to make
> that use case possible, or give quality advice or write good
> documentation for that use case.

If something important that wasn't considered comes up I'll certainly
listen if I'm on the Council, or argue for it if I'm not.  However,
Gentoo is not obligated to sustain every possible edge case just
because somebody claims it is useful, even if that edge case happened
to be supported in the past.

I'm skeptical that something will come up that hasn't been thought of
already, but it isn't like any of us have some kind of personal hate
for the eclass.  If something important comes up we'll think about it.

>
> So, agenda gets pushed to council -> council votes in favor of motion ->
> QA acts on council decision -> decisions empower them to prohibit
> blocking them -> somehow this is not forcing. The last jump in logic is
> questionable to me.
>

Nobody is forcing anybody to DO anything.  Nobody is forced to go
around editing ebuilds to remove the eclass.

Now, we ARE forcing people to NOT DO things.  If somebody removes the
games eclass from an ebuild you're forbidden to add it back.  You're
forbidden to port the eclass to EAPI6.  And so on.

I'm not pretending that the Council decision isn't binding.  That's
the whole point of having the Council.  If every decision were made on
unanimous consensus we wouldn't need one.  Obviously it isn't the
outcome we want but if people do oppose Council decisions they're
subject to QA/Comrel actions including temporary or permanent commit
access removal, and their ultimate appeal is to the Council they
opposed.  Democracy isn't anarchy.

> Patches *wouldn't* be welcome in this case, however. The patch in
> question would change default games.eclass variables to standard Gentoo
> paths. I know with certainty it wouldn't be accepted or welcomed. And
> with that knowledge, what would motivate me (or someone else, like
> someone with a relevant use case) to work toward getting that done? It
> would end up relegated to an overlay.

Patches to remove games.eclass from ebuilds would be welcome, and that
was my point.  The reason it is still around is that nobody has done
the work to get rid of it yet.

And if you want to suggest a better way, feel free.  If you want to
try to resurrect the games team, please do so.  Heaven only knows we
tried to get devs to revitalize it numerous times in the last year.

I don't know if the Council would accept a games eclass that was a
no-op by default but which exposed functionality to users via
environment variables.  I'd be interested into a discussion of the
pros/cons if you're volunteering to do the work to make it happen.
I'd be inclined to continue the policy that it is up to maintainers to
decide whether they're going to use it, otherwise we'll have endless
debates as to whether ktuberling or c-intercal fall under "games" or
not.  Something more generic and Gentoo Prefix-like might make it into
PMS and even become mandatory (and indeed Prefix is already a
potential solution which is fairly well-supported).

> Ignoring the use cases of others ensures that one day my use case will
> be on the stake. I wouldn't have worked toward becoming a developer if I
> was apathetic.

Gentoo has never claimed to offer a solution for every possible use
case, and every distro has its pros and cons.  I think Gentoo goes a
lot further than most distros to accommodate use cases.  If you
thought this debate was bad, you should go read the reaction when the
decision was made that not having /usr mounted during early boot was
not considered supported (though multiple mechanisms to get it mounted
during early boot exist).  Decisions like these don't mean that we
actively go out looking for ways to make our users lives miserable,
but it does mean that when somebody's bluetooth keyboard doesn't work
in single user mode we can WONTFIX them if they're not mounting /usr
early.

In any case, I think we'll get further looking for some way to move
forward than look backwards.  If you come up with a use case you
consider important, let's see if we can come up with a good way to
deal with it that is more sustainable.  You were the one to first
suggest looking at something like Prefix for a solution to your SSD
use case, and there is probably something to work with there.
Personally I think it is probably easier to just stick everything that
isn't huge on an SSD than to pick and choose package categories, but
you could of course run your games in a prefix, or something
prefix-like, or even in a container (though that might be less ideal
unless you're sticking X11 and everything else in there too, at which
point you might as well just stick your root on an SSD).

I understand where you're coming from.  There have been times at the
past where a package was being treecleaned and I'd tend to go on a
crusade to rescue it because somebody might still want to use it.  The
reality is that such reprieves tend to be temporary at best, unless
somebody who is genuinely interested in investing in the package is
willing to put the time in.  We want to help our users because we care
about them, but in the end if their itches aren't our own itches it
tends to fizzle out sooner or later.  Sometimes a use case gets
dropped not because it is a bad one, but simply because nobody cares
enough to make it work.  Instead, time gets put into maintaining other
things that are more interesting.  Java isn't in a pitiful state in
Gentoo because we all want to see it fail, it simply is the case that
most of us aren't interested enough to make it otherwise.  All it
takes to turn Gentoo into a Java paradise is a few really eager
volunteers to step in and make it so.  On the other hand, there are
other projects where Gentoo could probably be held up as a model
distro.

If you manage to drum up more interest in games and more active
contributions, I think that would be a good thing.

-- 
Rich