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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3280 bytes --]

Hello, everyone.

Over half a year has passed since Council decided upon the fate of
games in Gentoo. Over that period, the games team has neither showed
any will to respect the Council decisions, nor officially appealed to
them.

For this reason, the QA team would like to officially start supporting
the migration of ebuilds out of games.eclass. Any developer wishing to
help is more than welcome to take any games.eclass ebuild, bump its
revision and remove the games.eclass-specific bits from it. Updating to
EAPI 6 would also be welcome. A short update guide is provided at
the end of mail.

Please note that since this is considered a matter of QA action with
a long waiting period, no explicit approval from games team is
necessary to commit the conversion, nor games team is allowed to reject
or revert such commits as long as they are valid.

If you need any help doing that and the games team refuses to provide
it, please do not hesitate to contact me or ask in #gentoo-qa. If you
are interested in helping out with games, feel free to join games team
since it still lacks new members.

Thank you for all the help.


Migration notes
---------------

TL;DR: nothing special required, remove games.eclass and all
unnecessary games.eclass customization, and follow upstream. Make sure
not to break stuff.


The Council decisions can be summarized the following way:

1. The 'games' group, formerly used to control access to games, must
not be used. Games should be executable for all users like any other
program [1].

1a. For score files and similar writable shared data, the 'gamestat'
group (enewgroup gamestat 36) can be used. The old 'games' group is not
appropriate since sysadmins were expected to add users to it which
defeated its purpose.

2. Gentoo path customization for games must be removed and regular
install locations (without explicit control via GAMES_* variables)
should be used [2]:

2a. /usr/games and /etc/games directories are forbidden,

2b. /usr/share/games can be used for data if that directory is used
upstream,

2c. /var/games can be used for shared writable data.


This is mostly achieved through removing games.eclass inherit,
customization specific to it and replacing the helpers with generic PMS
helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
removed altogether.

In some cases it will also be beneficial to remove patching added to
support non-standard locations.

Please remember to always rev-bump and not edit in place, to ensure
proper upgrade. When dealing with dependencies, please make sure to
check if the package does not rely on dependency installing data in
a specific location. If that is the case, then you need to use
appropriate >= deps to ensure clean upgrade.

If you would like to report bugs requesting games.eclass removal,
please make them block the tracker [3].


[1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
[2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
[3]:https://bugs.gentoo.org/show_bug.cgi?id=574082

-- 
Best regards,
Michał Górny (on behalf of QA team)
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 3971 bytes --]

On 06/29/2016 10:11 AM, Michał Górny wrote:
> Hello, everyone.
> 
> Over half a year has passed since Council decided upon the fate of
> games in Gentoo. Over that period, the games team has neither showed
> any will to respect the Council decisions, nor officially appealed to
> them.
> 
> For this reason, the QA team would like to officially start supporting
> the migration of ebuilds out of games.eclass. Any developer wishing to
> help is more than welcome to take any games.eclass ebuild, bump its
> revision and remove the games.eclass-specific bits from it. Updating to
> EAPI 6 would also be welcome. A short update guide is provided at
> the end of mail.
> 
> Please note that since this is considered a matter of QA action with
> a long waiting period, no explicit approval from games team is
> necessary to commit the conversion, nor games team is allowed to reject
> or revert such commits as long as they are valid.
> 
> If you need any help doing that and the games team refuses to provide
> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
> are interested in helping out with games, feel free to join games team
> since it still lacks new members.
> 
> Thank you for all the help.
> 
> 
> Migration notes
> ---------------
> 
> TL;DR: nothing special required, remove games.eclass and all
> unnecessary games.eclass customization, and follow upstream. Make sure
> not to break stuff.
> 
> 
> The Council decisions can be summarized the following way:
> 
> 1. The 'games' group, formerly used to control access to games, must
> not be used. Games should be executable for all users like any other
> program [1].
> 
> 1a. For score files and similar writable shared data, the 'gamestat'
> group (enewgroup gamestat 36) can be used. The old 'games' group is not
> appropriate since sysadmins were expected to add users to it which
> defeated its purpose.
> 
> 2. Gentoo path customization for games must be removed and regular
> install locations (without explicit control via GAMES_* variables)
> should be used [2]:
> 
> 2a. /usr/games and /etc/games directories are forbidden,
> 
> 2b. /usr/share/games can be used for data if that directory is used
> upstream,
> 
> 2c. /var/games can be used for shared writable data.
> 
> 
> This is mostly achieved through removing games.eclass inherit,
> customization specific to it and replacing the helpers with generic PMS
> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
> removed altogether.
> 
> In some cases it will also be beneficial to remove patching added to
> support non-standard locations.
> 
> Please remember to always rev-bump and not edit in place, to ensure
> proper upgrade. When dealing with dependencies, please make sure to
> check if the package does not rely on dependency installing data in
> a specific location. If that is the case, then you need to use
> appropriate >= deps to ensure clean upgrade.
> 
> If you would like to report bugs requesting games.eclass removal,
> please make them block the tracker [3].
> 
> 
> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
> 
I'm glad to see some reach-out here and taking responsibility for
decisions. However, what does the QA team have to say about systems that
want games on other media (such as an SSD or separate HDD), or wish to
restrict the use of games on their system to certain accounts?

Bumping EAPI won't magically allow those to happen, and removing the
eclass *will* break those use cases. What's the "blessed" way to do those?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Rich Freeman]

On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell <zlg@gentoo.org> wrote:
> I'm glad to see some reach-out here and taking responsibility for
> decisions. However, what does the QA team have to say about systems that
> want games on other media (such as an SSD or separate HDD), or wish to
> restrict the use of games on their system to certain accounts?
>
> Bumping EAPI won't magically allow those to happen, and removing the
> eclass *will* break those use cases. What's the "blessed" way to do those?

Per-package install locations?  Sounds like a possible future EAPI
feature?  Of course, the real trick is when packages need to interact
and the files aren't in a fixed location.

In general right now I don't think we have a blessed way to install
stuff in non-standard locations.  Obviously you can fork an ebuild and
modify it, but if somebody wants to install KDE in /usr/kde/ and X11
into /usr/X11R6/ there isn't a clean way to do it.

-- 
Rich

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2947 bytes --]

On 06/29/2016 04:02 PM, Rich Freeman wrote:
> On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell <zlg@gentoo.org> wrote:
>> I'm glad to see some reach-out here and taking responsibility for
>> decisions. However, what does the QA team have to say about systems that
>> want games on other media (such as an SSD or separate HDD), or wish to
>> restrict the use of games on their system to certain accounts?
>>
>> Bumping EAPI won't magically allow those to happen, and removing the
>> eclass *will* break those use cases. What's the "blessed" way to do those?
> 
> Per-package install locations?  Sounds like a possible future EAPI
> feature?  Of course, the real trick is when packages need to interact
> and the files aren't in a fixed location.
> 
> In general right now I don't think we have a blessed way to install
> stuff in non-standard locations.  Obviously you can fork an ebuild and
> modify it, but if somebody wants to install KDE in /usr/kde/ and X11
> into /usr/X11R6/ there isn't a clean way to do it.
> 
A conversation or two I've had about it pointed to EPREFIX or some other
variable/function that (I was told) the Prefix team would know a bit
more about. I'm not even looking for something supported, per se.
Supporting ebuilds that can be installed anywhere is a bit much for
maintainers to worry about. But having the ability to, and having it
documented, would be great. Even if it's something like "Gentoo Linux
does not officially support or endorse this method, but here's how to
get it working". An EAPI bump may be nice on paper, but I have a feeling
implementing it would be a pain to support tree-wide.

Does the Prefix team have any recommendations in that department?

That's what I think this drama is about; changes being pushed from
people who don't work on games, then leaving these game maintainers (and
users) in the dark without a "correct" way to achieve what they're
after. We can do better than that, and it's solvable in a technical
manner, which is why I'm focused on it.

---

On the political side...

Do teams hold any authority (or veto power, whatever you want to call
it) over their own ebuilds? Is it reasonable to rip functionality out
from under a group of developers and tell them to deal with it?

I think teams deserve autonomy over their own ebuilds, and should
ideally follow QA guidelines *where reasonable*. Any good QA team should
have iron-clad reasons behind their decisions, and answers for
'what-ifs' that exist outside of the ideal perfection that QA tends to
operate in.

Removing eclasses without really good reason and without replacements
for missing use cases simply shouldn't happen. I wouldn't want that done
to me, and I'd definitely not (knowingly) help someone else do it.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 4331 bytes --]

On Wed, 29 Jun 2016 15:47:43 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> On 06/29/2016 10:11 AM, Michał Górny wrote:
> > Hello, everyone.
> > 
> > Over half a year has passed since Council decided upon the fate of
> > games in Gentoo. Over that period, the games team has neither showed
> > any will to respect the Council decisions, nor officially appealed to
> > them.
> > 
> > For this reason, the QA team would like to officially start supporting
> > the migration of ebuilds out of games.eclass. Any developer wishing to
> > help is more than welcome to take any games.eclass ebuild, bump its
> > revision and remove the games.eclass-specific bits from it. Updating to
> > EAPI 6 would also be welcome. A short update guide is provided at
> > the end of mail.
> > 
> > Please note that since this is considered a matter of QA action with
> > a long waiting period, no explicit approval from games team is
> > necessary to commit the conversion, nor games team is allowed to reject
> > or revert such commits as long as they are valid.
> > 
> > If you need any help doing that and the games team refuses to provide
> > it, please do not hesitate to contact me or ask in #gentoo-qa. If you
> > are interested in helping out with games, feel free to join games team
> > since it still lacks new members.
> > 
> > Thank you for all the help.
> > 
> > 
> > Migration notes
> > ---------------
> > 
> > TL;DR: nothing special required, remove games.eclass and all
> > unnecessary games.eclass customization, and follow upstream. Make sure
> > not to break stuff.
> > 
> > 
> > The Council decisions can be summarized the following way:
> > 
> > 1. The 'games' group, formerly used to control access to games, must
> > not be used. Games should be executable for all users like any other
> > program [1].
> > 
> > 1a. For score files and similar writable shared data, the 'gamestat'
> > group (enewgroup gamestat 36) can be used. The old 'games' group is not
> > appropriate since sysadmins were expected to add users to it which
> > defeated its purpose.
> > 
> > 2. Gentoo path customization for games must be removed and regular
> > install locations (without explicit control via GAMES_* variables)
> > should be used [2]:
> > 
> > 2a. /usr/games and /etc/games directories are forbidden,
> > 
> > 2b. /usr/share/games can be used for data if that directory is used
> > upstream,
> > 
> > 2c. /var/games can be used for shared writable data.
> > 
> > 
> > This is mostly achieved through removing games.eclass inherit,
> > customization specific to it and replacing the helpers with generic PMS
> > helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
> > The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
> > removed altogether.
> > 
> > In some cases it will also be beneficial to remove patching added to
> > support non-standard locations.
> > 
> > Please remember to always rev-bump and not edit in place, to ensure
> > proper upgrade. When dealing with dependencies, please make sure to
> > check if the package does not rely on dependency installing data in
> > a specific location. If that is the case, then you need to use
> > appropriate >= deps to ensure clean upgrade.
> > 
> > If you would like to report bugs requesting games.eclass removal,
> > please make them block the tracker [3].
> > 
> > 
> > [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
> > [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
> > [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
> >   
> I'm glad to see some reach-out here and taking responsibility for
> decisions. However, what does the QA team have to say about systems that
> want games on other media (such as an SSD or separate HDD), or wish to
> restrict the use of games on their system to certain accounts?
> 
> Bumping EAPI won't magically allow those to happen, and removing the
> eclass *will* break those use cases. What's the "blessed" way to do those?

If you want to do custom stuff, you're on your own. There are tricks to
do that (package.env, bashrc). Don't expect developers to patch packages
to satisfy your corner case.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 5808 bytes --]

On 06/29/2016 10:11 PM, Michał Górny wrote:
> On Wed, 29 Jun 2016 15:47:43 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
>> On 06/29/2016 10:11 AM, Michał Górny wrote:
>>> Hello, everyone.
>>>
>>> Over half a year has passed since Council decided upon the fate of
>>> games in Gentoo. Over that period, the games team has neither showed
>>> any will to respect the Council decisions, nor officially appealed to
>>> them.
>>>
>>> For this reason, the QA team would like to officially start supporting
>>> the migration of ebuilds out of games.eclass. Any developer wishing to
>>> help is more than welcome to take any games.eclass ebuild, bump its
>>> revision and remove the games.eclass-specific bits from it. Updating to
>>> EAPI 6 would also be welcome. A short update guide is provided at
>>> the end of mail.
>>>
>>> Please note that since this is considered a matter of QA action with
>>> a long waiting period, no explicit approval from games team is
>>> necessary to commit the conversion, nor games team is allowed to reject
>>> or revert such commits as long as they are valid.
>>>
>>> If you need any help doing that and the games team refuses to provide
>>> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
>>> are interested in helping out with games, feel free to join games team
>>> since it still lacks new members.
>>>
>>> Thank you for all the help.
>>>
>>>
>>> Migration notes
>>> ---------------
>>>
>>> TL;DR: nothing special required, remove games.eclass and all
>>> unnecessary games.eclass customization, and follow upstream. Make sure
>>> not to break stuff.
>>>
>>>
>>> The Council decisions can be summarized the following way:
>>>
>>> 1. The 'games' group, formerly used to control access to games, must
>>> not be used. Games should be executable for all users like any other
>>> program [1].
>>>
>>> 1a. For score files and similar writable shared data, the 'gamestat'
>>> group (enewgroup gamestat 36) can be used. The old 'games' group is not
>>> appropriate since sysadmins were expected to add users to it which
>>> defeated its purpose.
>>>
>>> 2. Gentoo path customization for games must be removed and regular
>>> install locations (without explicit control via GAMES_* variables)
>>> should be used [2]:
>>>
>>> 2a. /usr/games and /etc/games directories are forbidden,
>>>
>>> 2b. /usr/share/games can be used for data if that directory is used
>>> upstream,
>>>
>>> 2c. /var/games can be used for shared writable data.
>>>
>>>
>>> This is mostly achieved through removing games.eclass inherit,
>>> customization specific to it and replacing the helpers with generic PMS
>>> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
>>> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
>>> removed altogether.
>>>
>>> In some cases it will also be beneficial to remove patching added to
>>> support non-standard locations.
>>>
>>> Please remember to always rev-bump and not edit in place, to ensure
>>> proper upgrade. When dealing with dependencies, please make sure to
>>> check if the package does not rely on dependency installing data in
>>> a specific location. If that is the case, then you need to use
>>> appropriate >= deps to ensure clean upgrade.
>>>
>>> If you would like to report bugs requesting games.eclass removal,
>>> please make them block the tracker [3].
>>>
>>>
>>> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
>>> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
>>> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
>>>   
>> I'm glad to see some reach-out here and taking responsibility for
>> decisions. However, what does the QA team have to say about systems that
>> want games on other media (such as an SSD or separate HDD), or wish to
>> restrict the use of games on their system to certain accounts?
>>
>> Bumping EAPI won't magically allow those to happen, and removing the
>> eclass *will* break those use cases. What's the "blessed" way to do those?
> 
> If you want to do custom stuff, you're on your own. There are tricks to
> do that (package.env, bashrc). Don't expect developers to patch packages
> to satisfy your corner case.
> 

Why not document those tricks in the same section of the wiki that
indicates games.eclass's deprecation? A heads-up with a link?
_Something_. This isn't my use case, but we owe it to users to give them
ways forward when we break things, even if they aren't what we
personally use. If another developer (or team of developers) rendered
your use case(s) unsupported or flippantly wrote it off as a corner case
(with no documentation on restoring your previous use case), what would
you do?

Other breakages have been handled much better, such as the separate /usr
switch. Mentions of that were almost always followed up with "If you
wish to keep this, use an initramfs". That is an example of breakage
handled correctly: the change is explained, use cases that would break
were identified, and a way was given to users of that use case to move
forward and remain current.

Your handling of this eclass deprecation is little more than a heads-up,
"We're breaking your use case and we don't consider it worth writing a
paragraph's worth of documentation to guide you after the switch." Is
that what you find acceptable? Would you support a developer doing that
to another part of the tree?

Other changes in Gentoo have come along that were handled better *and*
were more impactful. This situation deserves no less consideration.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Rich Freeman]

On Thu, Jun 30, 2016 at 12:54 AM, Daniel Campbell <zlg@gentoo.org> wrote:
>
> Do teams hold any authority (or veto power, whatever you want to call
> it) over their own ebuilds? Is it reasonable to rip functionality out
> from under a group of developers and tell them to deal with it?

Generally speaking, yes.  If somebody has an issue with a project's
policies they should try to work it out with the project lead, and
failing that with the council.  In this particular case the Council
has issued decisions, and these override all projects.

> I think teams deserve autonomy over their own ebuilds, and should
> ideally follow QA guidelines *where reasonable*.

QA is a special project (as is Comrel).  They do not require the
approval of other projects to take action.  If somebody has a concern
with their actions they may be appealed to the Council.  The Council
can of course decide on whether QA is acting reasonably.

We can't just let any project in Gentoo decide what is or isn't
reasonable with finality.  Any developer can start a Gentoo project
(that's a good thing), and we'd have chaos if they all could just hold
ultimate veto on what goes into their part of the tree.

If you want ultimate veto over what goes in, just do your work in an
overlay.  Nobody will even have the access to touch your stuff.

For the most part we try to be hands-off with this stuff and when you
look at the months it took leading up to the Council decisions on the
games issues, it is fairly obvious that we didn't want to meddle more
than absolutely necessary.  For the most part the changes just make
games like any other package, which is a fairly conservative change.
If somebody wanted to install all text editors into /usr/texteditors/
I'm sure we'd have ended up having the same discussion at some point.

Don't get me wrong - if somebody comes up with a reasonable way to let
users control where packages get installed I'm all for it.  I see that
use case as having validity, and beyond games as well.

Certainly you could install games in a prefix-like environment as you
suggested.  Gentoo Prefix should certainly work on Gentoo.

-- 
Rich

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 7200 bytes --]

On Wed, 29 Jun 2016 22:37:27 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> On 06/29/2016 10:11 PM, Michał Górny wrote:
> > On Wed, 29 Jun 2016 15:47:43 -0700
> > Daniel Campbell <zlg@gentoo.org> wrote:
> >   
> >> On 06/29/2016 10:11 AM, Michał Górny wrote:  
> >>> Hello, everyone.
> >>>
> >>> Over half a year has passed since Council decided upon the fate of
> >>> games in Gentoo. Over that period, the games team has neither showed
> >>> any will to respect the Council decisions, nor officially appealed to
> >>> them.
> >>>
> >>> For this reason, the QA team would like to officially start supporting
> >>> the migration of ebuilds out of games.eclass. Any developer wishing to
> >>> help is more than welcome to take any games.eclass ebuild, bump its
> >>> revision and remove the games.eclass-specific bits from it. Updating to
> >>> EAPI 6 would also be welcome. A short update guide is provided at
> >>> the end of mail.
> >>>
> >>> Please note that since this is considered a matter of QA action with
> >>> a long waiting period, no explicit approval from games team is
> >>> necessary to commit the conversion, nor games team is allowed to reject
> >>> or revert such commits as long as they are valid.
> >>>
> >>> If you need any help doing that and the games team refuses to provide
> >>> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
> >>> are interested in helping out with games, feel free to join games team
> >>> since it still lacks new members.
> >>>
> >>> Thank you for all the help.
> >>>
> >>>
> >>> Migration notes
> >>> ---------------
> >>>
> >>> TL;DR: nothing special required, remove games.eclass and all
> >>> unnecessary games.eclass customization, and follow upstream. Make sure
> >>> not to break stuff.
> >>>
> >>>
> >>> The Council decisions can be summarized the following way:
> >>>
> >>> 1. The 'games' group, formerly used to control access to games, must
> >>> not be used. Games should be executable for all users like any other
> >>> program [1].
> >>>
> >>> 1a. For score files and similar writable shared data, the 'gamestat'
> >>> group (enewgroup gamestat 36) can be used. The old 'games' group is not
> >>> appropriate since sysadmins were expected to add users to it which
> >>> defeated its purpose.
> >>>
> >>> 2. Gentoo path customization for games must be removed and regular
> >>> install locations (without explicit control via GAMES_* variables)
> >>> should be used [2]:
> >>>
> >>> 2a. /usr/games and /etc/games directories are forbidden,
> >>>
> >>> 2b. /usr/share/games can be used for data if that directory is used
> >>> upstream,
> >>>
> >>> 2c. /var/games can be used for shared writable data.
> >>>
> >>>
> >>> This is mostly achieved through removing games.eclass inherit,
> >>> customization specific to it and replacing the helpers with generic PMS
> >>> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
> >>> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
> >>> removed altogether.
> >>>
> >>> In some cases it will also be beneficial to remove patching added to
> >>> support non-standard locations.
> >>>
> >>> Please remember to always rev-bump and not edit in place, to ensure
> >>> proper upgrade. When dealing with dependencies, please make sure to
> >>> check if the package does not rely on dependency installing data in
> >>> a specific location. If that is the case, then you need to use
> >>> appropriate >= deps to ensure clean upgrade.
> >>>
> >>> If you would like to report bugs requesting games.eclass removal,
> >>> please make them block the tracker [3].
> >>>
> >>>
> >>> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
> >>> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
> >>> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
> >>>     
> >> I'm glad to see some reach-out here and taking responsibility for
> >> decisions. However, what does the QA team have to say about systems that
> >> want games on other media (such as an SSD or separate HDD), or wish to
> >> restrict the use of games on their system to certain accounts?
> >>
> >> Bumping EAPI won't magically allow those to happen, and removing the
> >> eclass *will* break those use cases. What's the "blessed" way to do those?  
> > 
> > If you want to do custom stuff, you're on your own. There are tricks to
> > do that (package.env, bashrc). Don't expect developers to patch packages
> > to satisfy your corner case.
> >   
> 
> Why not document those tricks in the same section of the wiki that
> indicates games.eclass's deprecation? A heads-up with a link?

Wiki is public. You are free to provide useful information if you like.
I don't feel like working on unsupported hacks that won't work reliably
and don't give much benefit to anyone. Just please keep that on
a separate page so that people don't think it's officially supported.

> _Something_. This isn't my use case, but we owe it to users to give them
> ways forward when we break things, even if they aren't what we
> personally use.

So why are you mentioning it? It looks like you jump out of the blue
like your life suddenly stopped to make sense, and go accusing random
people of being part of a process that started a few years back.

The games.eclass design supported many corner cases. They were weighed,
and it was decided that we prefer to go for uniformity, standards
compliance and simplicity, rather than working on support for a few
corner cases on non-clearly selected packages.

> If another developer (or team of developers) rendered
> your use case(s) unsupported or flippantly wrote it off as a corner case
> (with no documentation on restoring your previous use case), what would
> you do?

I either agree or disagree. If I disagree, I enter the discussion or
start it as necessary, etc. It's all in the procedures.

> Other breakages have been handled much better, such as the separate /usr
> switch. Mentions of that were almost always followed up with "If you
> wish to keep this, use an initramfs". That is an example of breakage
> handled correctly: the change is explained, use cases that would break
> were identified, and a way was given to users of that use case to move
> forward and remain current.

You are comparing two completely different changes. We are not
*breaking* user's systems. Systems will still boot, games will still
work.

> Your handling of this eclass deprecation is little more than a heads-up,
> "We're breaking your use case and we don't consider it worth writing a
> paragraph's worth of documentation to guide you after the switch." Is
> that what you find acceptable? Would you support a developer doing that
> to another part of the tree?
> 
> Other changes in Gentoo have come along that were handled better *and*
> were more impactful. This situation deserves no less consideration.

Are you talking about user or developer documentation? Because I'm
really lost in your argumentation.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]

On Wed, 29 Jun 2016 21:54:44 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> That's what I think this drama is about; changes being pushed from
> people who don't work on games, then leaving these game maintainers (and
> users) in the dark without a "correct" way to achieve what they're
> after. We can do better than that, and it's solvable in a technical
> manner, which is why I'm focused on it.

I'd really appreciate if you did some research before accusing people.

> On the political side...
> 
> Do teams hold any authority (or veto power, whatever you want to call
> it) over their own ebuilds? Is it reasonable to rip functionality out
> from under a group of developers and tell them to deal with it?
> 
> I think teams deserve autonomy over their own ebuilds, [...]

No, they do not and I will not allow that to happen ever again. And I'm
pretty sure I'm not the only one here that was unhappy with the way
Games team pushed everyone around over the years.

If you want autonomy, fork Gentoo or use your own repository. The core
Gentoo repository is community-maintained -- either live with it, or
leave. We do not need more people causing massive community damage for
years with nobody being bold enough to stop them.

People and teams have reasonable right to develop policies and maintain
their own packages. However, they have no right to assume sole
ownership of all packages with generic characteristic, and hold it
for years while preventing anyone from having any saying on anything.

Rephrasing Rich's words, how would you feel if I established 'Text
editors' project and claimed final saying on every single text editor
in Gentoo? Then I would develop policies I find useful, ignore any
input, ignore join requests and discourage anyone from contributing.
Is that the Gentoo you desire?

> and should
> ideally follow QA guidelines *where reasonable*. Any good QA team should
> have iron-clad reasons behind their decisions, and answers for
> 'what-ifs' that exist outside of the ideal perfection that QA tends to
> operate in.

The whole point of QA is to provide good quality *everywhere*, and it
is *unacceptable* to have developers decide if they want to follow
policies or not. It is reasonable to adjust the policies as necessary,
or allow grace periods. But there is no point in having policies that
are fully optional depending on the mood of the developer.

That said, this is completely irrelevant to the topic at hand. This
isn't QA's decision. It's a long process started by individual
developers *interested in helping out with games* years ago, which
ended up with Council appeal. The source of the policy is the Council,
not QA.

QA is merely concerned with the fact that Games team ignores
the policies established by the Council. This results in two different
layouts being deployed over the repository which results in increased
confusion (which you are victim of), and decreased quality. QA offers
to help in solving that.

> Removing eclasses without really good reason and without replacements
> for missing use cases simply shouldn't happen. I wouldn't want that done
> to me, and I'd definitely not (knowingly) help someone else do it.

Your disagreement with the rationale does not make it bad.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 7928 bytes --]

On 06/30/2016 06:17 AM, Michał Górny wrote:
> On Wed, 29 Jun 2016 21:54:44 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
>> That's what I think this drama is about; changes being pushed from
>> people who don't work on games, then leaving these game maintainers (and
>> users) in the dark without a "correct" way to achieve what they're
>> after. We can do better than that, and it's solvable in a technical
>> manner, which is why I'm focused on it.
> 
> I'd really appreciate if you did some research before accusing people.

I've read the council meetings that I was able to find on it and have
explored the perspectives of both sides of the subject. What research
are you asking for? I've not attacked anyone.
> 
>> On the political side...
>>
>> Do teams hold any authority (or veto power, whatever you want to call
>> it) over their own ebuilds? Is it reasonable to rip functionality out
>> from under a group of developers and tell them to deal with it?
>>
>> I think teams deserve autonomy over their own ebuilds, [...]
> 
> No, they do not and I will not allow that to happen ever again. And I'm
> pretty sure I'm not the only one here that was unhappy with the way
> Games team pushed everyone around over the years.
> 
> If you want autonomy, fork Gentoo or use your own repository. The core
> Gentoo repository is community-maintained -- either live with it, or
> leave. We do not need more people causing massive community damage for
> years with nobody being bold enough to stop them.
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.

This has little to do with what I want. I don't seek any of the use
cases that games.eclass made possible, but that doesn't mean my use
cases won't be axed in the future with the same lack of care and for
similarly petty reasons.

> 
> People and teams have reasonable right to develop policies and maintain
> their own packages. However, they have no right to assume sole
> ownership of all packages with generic characteristic, and hold it
> for years while preventing anyone from having any saying on anything.
> 
> Rephrasing Rich's words, how would you feel if I established 'Text
> editors' project and claimed final saying on every single text editor
> in Gentoo? Then I would develop policies I find useful, ignore any
> input, ignore join requests and discourage anyone from contributing.
> Is that the Gentoo you desire?
No, it's not the Gentoo I desire. I've seen that claim thrown around and
I've not seen any evidence of it happening follow it. I get it if you or
others have a vendetta against the games team -- I don't know any of
them really -- sometimes people don't get along. But ripping out the
eclass is a "solution" that creates more problems than it solves.
Changing its default prefix values to follow Gentoo's standard and
allowing users to change it meets the needs of both parties, and yet it
seems nobody considered that option. Rich suggested maybe its
functionality could be put into a later EAPI, but as he noted there are
hurdles in generalizing that behavior. If its values default to match
Gentoo's, then only the people who need the path flexibility will need
to change it. That's one of the recent trends for us lately, isn't it?
Leave sane defaults, but if people want to change them and/or break
things, they're free to.

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?
> 
>> and should
>> ideally follow QA guidelines *where reasonable*. Any good QA team should
>> have iron-clad reasons behind their decisions, and answers for
>> 'what-ifs' that exist outside of the ideal perfection that QA tends to
>> operate in.
> 
> The whole point of QA is to provide good quality *everywhere*, and it
> is *unacceptable* to have developers decide if they want to follow
> policies or not. It is reasonable to adjust the policies as necessary,
> or allow grace periods. But there is no point in having policies that
> are fully optional depending on the mood of the developer.
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?

A key ingredient to QA is knowing quality code when one sees it, and
fully understanding the use cases that a given set of code makes
possible. Ideally, they also understand and suggest best practices so
people are aware of how to 'color inside the lines'.

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.
> 
> That said, this is completely irrelevant to the topic at hand. This
> isn't QA's decision. It's a long process started by individual
> developers *interested in helping out with games* years ago, which
> ended up with Council appeal. The source of the policy is the Council,
> not QA.
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.
> 
> QA is merely concerned with the fact that Games team ignores
> the policies established by the Council. This results in two different
> layouts being deployed over the repository which results in increased
> confusion (which you are victim of), and decreased quality. QA offers
> to help in solving that.
> 
>> Removing eclasses without really good reason and without replacements
>> for missing use cases simply shouldn't happen. I wouldn't want that done
>> to me, and I'd definitely not (knowingly) help someone else do it.
> 
> Your disagreement with the rationale does not make it bad.
> 
The rationale goes against what QA supposedly stands for (Quality
Assurance). It breaks use cases and breaks ebuilds that use the eclass.
In what way does the quality improve that changing games.eclass's
default prefixes to match the rest of the tree doesn't also solve?

Have you read the eclass? All the variables are at the top and we can
change the defaults with no issue, while people who depend on that
eclass can set the variables in make.conf or some other place. For
those, there are news items.

Instead, with things as they are now, ebuilds get broken and user
expectations get turned on their head, upstream (us) doesn't give them
any hints on how to go forward, and until every games.eclass-depending
ebuild gets fixed, it'll have warnings and/or die() calls. The *only*
benefit gained from this is the unicorn "every package is treated the
same", except when they're not (@system target, coreutils and friends
ring a bell?).

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.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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@gentoo.org> 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

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

[Matt Turner]

On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell <zlg@gentoo.org> wrote:
> I'm glad to see some reach-out here and taking responsibility for
> decisions. However, what does the QA team have to say about systems that
> want games on other media (such as an SSD or separate HDD), or wish to
> restrict the use of games on their system to certain accounts?

Has anyone complained about either of these features going away? If
they're purely theoretical concerns...

The games.eclass saga has gone on plenty long enough. I would much
prefer that we not relitigate it. I understand that you may not have
been around when most of it happened initially, but please understand
that it's not feasible to reconsider every decision when new
developers join the project.

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

[Duncan]

Rich Freeman posted on Thu, 30 Jun 2016 20:24:43 -0400 as excerpted:

> 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.

Indeed.  

This bit of the previous discussion has been missing from this round so 
far, but FWIW, one of the big frustrations from the council side and I 
think from most looking on (certainly me) was that they /begged/ games 
team to step up and present a reasonable defense of their policy and 
provide some sort of presumably opposing viewpoint from which to work 
toward a compromise somewhere in the middle.

And they begged games team to work with them to let other devs on the 
team and help get them up and running with policies, etc, as bugs were 
piling up.

But the problem was, games team was pretty much MIA, in terms of any form 
of communication whatsoever.  While some individual games team members 
were still maintaining their individual ebuilds, /nobody/ was willing or 
able to speak for the team, and to help with other ebuilds that were 
effectively left rotting, because games team, at least as an actually 
working /team/, simply /wasn't/, any more.

There were volunteers who /tried/ to get on the team.  No ack from the 
lead or anybody to speak for the team.  Nobody to bring them upto speed 
on policies, etc.  And nobody answered council or QA questions about why, 
and what could be done to fix it.  And the eclass was left rotting as 
well, an area that's definitely QA's territory, again seemingly with 
anybody willing to reply apparently vanished from earth.

Meanwhile, games were flourishing in overlays, because games in gentoo 
itself had become a toxic wasteland with the absent games team asserting 
control, but with nobody willing or able to do anything about it.


So eventually, after repeated /begging/ from both QA and council with, 
essentially, crickets in response...

Council had to act to bring back some sort of sanity.  Including working 
to finally close a long open security bug on at least one game /because/ 
of the way gentoo was handling things -- it wasn't a problem on other 
distros because they didn't have a special games group to deal with.

Even then, /nobody/ was willing to volunteer to lead the newly reforming 
games team, and few were willing to even be members.  By this time 
everything involved with it was simply too toxic, I guess.

So what council did first, was basically formerly declare than anyone 
that wanted could commit new (not yet in-tree) games on their own, 
without having to fear games team vetoing or reverting.  And the eclass 
was deprecated as effectively unmaintained, simply recognizing the fact.

And even /that/ was basically the minimum necessary to get some 
functionality back, hoping it might wake someone up on games team to at 
least have someone to work with and to try to compromise with.

But six months later, we still don't see a newly reactivated and gaining 
health games team trying to get back in the game, as it were.

And the /biggest/ problem, we /still/ don't have anyone of the former 
members (remember, no one further could join as it was too dysfunctional) 
volunteering to step up and actually head the thing, maintain or arrange 
for maintenance of the eclass, etc, despite the fact that some are still 
raising objections to moving ebuilds off the eclass, etc.

Bottom line, the former games team is /still/ dysfunctional and basically 
dead, and can't even pull itself together enough for there to be any 
other realistic alternative /but/ to have QA continue to work on moving 
existing ebuilds off of it, as proposed here.  This has gone on for 
/years/, and truth be, it's really a bit late now, even if games team 
/were/ to suddenly resurrect and try to reverse things now.

But that /still/ isn't happening.  There's others objecting, still saying 
it's not their use-case but it's a shame... and it is a shame... but at 
some point, that stinking rotting corpse just /must/ be buried or burned 
or otherwise disposed of.  Otherwise, it's just a worsening public health 
hazard, however much of a shame that death might be.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]

On 06/30/2016 06:02 PM, Matt Turner wrote:
> On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell <zlg@gentoo.org> wrote:
>> I'm glad to see some reach-out here and taking responsibility for
>> decisions. However, what does the QA team have to say about systems that
>> want games on other media (such as an SSD or separate HDD), or wish to
>> restrict the use of games on their system to certain accounts?
> 
> Has anyone complained about either of these features going away? If
> they're purely theoretical concerns...
> 
> The games.eclass saga has gone on plenty long enough. I would much
> prefer that we not relitigate it. I understand that you may not have
> been around when most of it happened initially, but please understand
> that it's not feasible to reconsider every decision when new
> developers join the project.
> 
I understand where you're coming from, but a lack of yelling or
complaining isn't logically equivalent to consensus. It's a fair point
to make, though. We don't know until we ask, so I'll post something on
gentoo-user about it.

I also understand that I'm new and we're not special. I'm not sure where
I conveyed that. It's healthy to look back and reassess or reconsider
decisions. Policies, standards, or even accurate consensus can't be
assessed unless they're checked every once in a while. If there are
other strange decisions you feel need attention, I'm all eyes. :)

~zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Thu, 30 Jun 2016 23:27:18 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> On 06/30/2016 06:02 PM, Matt Turner wrote:
> > On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell <zlg@gentoo.org> wrote:  
> >> I'm glad to see some reach-out here and taking responsibility for
> >> decisions. However, what does the QA team have to say about systems that
> >> want games on other media (such as an SSD or separate HDD), or wish to
> >> restrict the use of games on their system to certain accounts?  
> > 
> > Has anyone complained about either of these features going away? If
> > they're purely theoretical concerns...
> > 
> > The games.eclass saga has gone on plenty long enough. I would much
> > prefer that we not relitigate it. I understand that you may not have
> > been around when most of it happened initially, but please understand
> > that it's not feasible to reconsider every decision when new
> > developers join the project.
> >   
> I understand where you're coming from, but a lack of yelling or
> complaining isn't logically equivalent to consensus. It's a fair point
> to make, though. We don't know until we ask, so I'll post something on
> gentoo-user about it.

Did you know that Gentoo users are more likely to want something once
you tell them they can want it? Even if it doesn't really make any
sense, and they never felt like needing it in the past.

So you're likely to make more noise than it's worth, and turn a minor
loss into a major one. 'Hey, I'm telling you you can do X since we're
removing it, enjoy it for a few days!'

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[R0b0t1]

On Fri, Jul 1, 2016 at 1:31 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Thu, 30 Jun 2016 23:27:18 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
>
>> On 06/30/2016 06:02 PM, Matt Turner wrote:
>> > On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell <zlg@gentoo.org> wrote:
>> >> I'm glad to see some reach-out here and taking responsibility for
>> >> decisions. However, what does the QA team have to say about systems that
>> >> want games on other media (such as an SSD or separate HDD), or wish to
>> >> restrict the use of games on their system to certain accounts?
>> >
>> > Has anyone complained about either of these features going away? If
>> > they're purely theoretical concerns...
>> >
>> > The games.eclass saga has gone on plenty long enough. I would much
>> > prefer that we not relitigate it. I understand that you may not have
>> > been around when most of it happened initially, but please understand
>> > that it's not feasible to reconsider every decision when new
>> > developers join the project.
>> >
>> I understand where you're coming from, but a lack of yelling or
>> complaining isn't logically equivalent to consensus. It's a fair point
>> to make, though. We don't know until we ask, so I'll post something on
>> gentoo-user about it.
>
> Did you know that Gentoo users are more likely to want something once
> you tell them they can want it? Even if it doesn't really make any
> sense, and they never felt like needing it in the past.
>
> So you're likely to make more noise than it's worth, and turn a minor
> loss into a major one. 'Hey, I'm telling you you can do X since we're
> removing it, enjoy it for a few days!'
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

I wanted it, but didn't know it existed. I found more utility in
virtualizing machines to run games; the problem disappears with a new
/.

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]

On 06/30/2016 11:31 PM, Michał Górny wrote:
> On Thu, 30 Jun 2016 23:27:18 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
>> On 06/30/2016 06:02 PM, Matt Turner wrote:
>>> On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell <zlg@gentoo.org> wrote:  
>>>> I'm glad to see some reach-out here and taking responsibility for
>>>> decisions. However, what does the QA team have to say about systems that
>>>> want games on other media (such as an SSD or separate HDD), or wish to
>>>> restrict the use of games on their system to certain accounts?  
>>>
>>> Has anyone complained about either of these features going away? If
>>> they're purely theoretical concerns...
>>>
>>> The games.eclass saga has gone on plenty long enough. I would much
>>> prefer that we not relitigate it. I understand that you may not have
>>> been around when most of it happened initially, but please understand
>>> that it's not feasible to reconsider every decision when new
>>> developers join the project.
>>>   
>> I understand where you're coming from, but a lack of yelling or
>> complaining isn't logically equivalent to consensus. It's a fair point
>> to make, though. We don't know until we ask, so I'll post something on
>> gentoo-user about it.
> 
> Did you know that Gentoo users are more likely to want something once
> you tell them they can want it? Even if it doesn't really make any
> sense, and they never felt like needing it in the past.
> 
> So you're likely to make more noise than it's worth, and turn a minor
> loss into a major one. 'Hey, I'm telling you you can do X since we're
> removing it, enjoy it for a few days!'
> 
I don't have that grim of an outlook on our userbase. A few simple
questions could create numbers that others can use to infer things from:

1. "Have you used the functionality of games.eclass before?"
2. "Would losing it severely worsen your use case?"
3. "If yes to #2, what _is_ your use case, and what would make it better?"

Enough input could give us some insight, even if that insight turns out
to be "nobody cares". You can't know what you don't ask.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 11378 bytes --]

On 06/30/2016 05:24 PM, Rich Freeman wrote:
> On Thu, Jun 30, 2016 at 7:19 PM, Daniel Campbell <zlg@gentoo.org> 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.

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?

> 
> 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.

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 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.

>> 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.

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.

> 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.
> 
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.

There's nothing wrong with that, technically speaking, but it belies the
story of "Patches welcome, everyone can contribute."

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.

---

To all other points, thanks for clarifying the operating structure of
Gentoo. I'm going to wait on my gentoo-user survey to give us some
concrete results to work with; be they in favor of games.eclass or
apathetic. It will at least reflect reality.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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@gentoo.org> 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