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

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

[Daniel Campbell]

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

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

[Daniel Campbell]

On 06/30/2016 11:31 PM, Michał Górny wrote:
> On Thu, 30 Jun 2016 23:27:18 -0700
> Daniel Campbell  wrote:
> 
>> On 06/30/2016 06:02 PM, Matt Turner wrote:
>>> On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell  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



signature.asc
Description: OpenPGP digital signature

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  wrote:
> On Thu, 30 Jun 2016 23:27:18 -0700
> Daniel Campbell  wrote:
>
>> On 06/30/2016 06:02 PM, Matt Turner wrote:
>> > On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell  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
> 

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

[Michał Górny]

On Thu, 30 Jun 2016 23:27:18 -0700
Daniel Campbell  wrote:

> On 06/30/2016 06:02 PM, Matt Turner wrote:
> > On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell  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



pgpPo632sYvR4.pgp
Description: OpenPGP digital signature

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

[Daniel Campbell]

On 06/30/2016 06:02 PM, Matt Turner wrote:
> On Wed, Jun 29, 2016 at 3:47 PM, Daniel Campbell  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



signature.asc
Description: OpenPGP digital signature

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

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

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

[Daniel Campbell]

On 06/30/2016 06:17 AM, Michał Górny wrote:
> On Wed, 29 Jun 2016 21:54:44 -0700
> Daniel Campbell  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 

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

[Michał Górny]

On Wed, 29 Jun 2016 21:54:44 -0700
Daniel Campbell  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



pgpr0npxdXcCX.pgp
Description: OpenPGP digital signature

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

[Michał Górny]

On Wed, 29 Jun 2016 22:37:27 -0700
Daniel Campbell  wrote:

> On 06/29/2016 10:11 PM, Michał Górny wrote:
> > On Wed, 29 Jun 2016 15:47:43 -0700
> > Daniel Campbell  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 

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

[Daniel Campbell]

On 06/29/2016 10:11 PM, Michał Górny wrote:
> On Wed, 29 Jun 2016 15:47:43 -0700
> Daniel Campbell  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, 

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

[Michał Górny]

On Wed, 29 Jun 2016 15:47:43 -0700
Daniel Campbell  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



pgptJSC38tSn6.pgp
Description: OpenPGP digital signature

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

[Daniel Campbell]

On 06/29/2016 04:02 PM, Rich Freeman wrote:
> On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell  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



signature.asc
Description: OpenPGP digital signature

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

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



signature.asc
Description: OpenPGP digital signature

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

[Michał Górny]

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)



pgpRKmomoXXMm.pgp
Description: OpenPGP digital signature