[gentoo-dev] Re: The request to abolish games team policy

[Ulrich Mueller]

> On Mon, 7 Jul 2014, Michał Górny wrote:

> iii. that the games group along with the game-specific install tree
> should be deprecated and phased out. Games should be installed alike
> any other applications.

The install locations (/usr/games, /usr/share/games, /var/games, etc.)
are specified by the FHS. So they're not entirely games team policy.

Ulrich


pgpJt9yhIEkOb.pgp
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

[Rich Freeman]

On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller  wrote:
>> On Mon, 7 Jul 2014, Michał Górny wrote:
>
>> iii. that the games group along with the game-specific install tree
>> should be deprecated and phased out. Games should be installed alike
>> any other applications.
>
> The install locations (/usr/games, /usr/share/games, /var/games, etc.)
> are specified by the FHS. So they're not entirely games team policy.

I just checked some random packages on Debian and found that adherence
to this path there is mixed.  I'd say the majority of packages I
checked installed in /usr/games, but quite a few did not.  Many of the
ones that tended to install there were games that probably predate the
Linux kernel, but this was by no means exclusively the case.

Their official policy says that games should go in /usr/games though.
They also state "Each game decides on its own security policy."  They
apparently only use a games group for things like high scores and save
game dirs, and use sgid on the binary to accomplish this (minimizing
its use in general).  (Note, I don't run Debian much, so this is the
result of a quick scan of their policies and the real world may vary.)

Just another data point - we're not obligated to do things one way or
the other...

Rich

[gentoo-dev] Re: The request to abolish games team policy

[Michael Palimaka]

On 07/08/2014 07:45 AM, Michał Górny wrote:
> Dear Community,
> 
> First of all, please do not take this personally. I don't want to
> attack any member of the games team or the team in general. I respect
> their experience and long-term contribution to Gentoo. However,
> I strongly disagree with the policy games team has established and I
> believe that their actions do not serve the best interest of Gentoo.
> 
> I am therefore going to propose this request to the next Council. Since
> this will likely require a fair amount of prior discussion, I would
> like to start it already, hopefully reaching at least some point before
> the appropriate Council meeting.
> 
> 
> I would like to ask the Council to abolish the following policies that
> have been established by the games team:
> 
> 1. that the games team has authority over the actual maintainers
> on every game ebuild,
> 
> 2. that every ebuild has to inherit games.eclass as the last eclass
> inherited [1], even if it actually increases the ebuild size rather
> than helping,
> 
> 3. that games must adhere to games team-specific install locations
> and ownership rules, shortly listed in [2].

Why is Council intervention needed to abolish these policies? They're
not binding.
As far as I know, the games team has no special status so like any other
project they can recommend whatever they want - nobody is obliged to
listen (I certainly don't).

Re: [gentoo-dev] Re: The request to abolish games team policy

[Rich Freeman]

On Tue, Jul 8, 2014 at 6:52 AM, Michael Palimaka  wrote:
> On 07/08/2014 07:45 AM, Michał Górny wrote:
>>
>> 1. that the games team has authority over the actual maintainers
>> on every game ebuild,
>>
>
> Why is Council intervention needed to abolish these policies? They're
> not binding.
> As far as I know, the games team has no special status so like any other
> project they can recommend whatever they want - nobody is obliged to
> listen (I certainly don't).
>

Gentoo projects should probably be viewed as having more authority
than random package maintainers, though not in any absolute sense.
However, they should also generally allow anybody to join them, and
must have an annual election of lead.  The Games project hasn't been
migrated to the Wiki and the page hasn't been touched since 2006, so
I'm a bit skeptical of that (though for all I know they're active and
the membership/lead just hasn't changed).  To the extent that we give
projects a preferential status with regard to authority/etc it really
should only be to the extent that projects "uphold their side of the
bargain" by following the rules.

Bureaucracy aside, for something as broad as "Games" I think we should
keep distro-level policy on the light side.  I don't think that it
makes sense to try to establish a security model that amounts to
SELinux-light.  Admins of multi-user systems have much better tools
these days to control what happens on their systems.  I don't have a
problem with generally trying to follow FHS, but I don't see the need
for debates over where kpat goes.

But, that is my own personal two cents.  I'm interested in what active
members of the games project have to offer.

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

[Michał Górny]

Dnia 2014-07-08, o godz. 20:52:49
Michael Palimaka  napisał(a):

> On 07/08/2014 07:45 AM, Michał Górny wrote:
> > I would like to ask the Council to abolish the following policies that
> > have been established by the games team:
> > 
> > 1. that the games team has authority over the actual maintainers
> > on every game ebuild,
> > 
> > 2. that every ebuild has to inherit games.eclass as the last eclass
> > inherited [1], even if it actually increases the ebuild size rather
> > than helping,
> > 
> > 3. that games must adhere to games team-specific install locations
> > and ownership rules, shortly listed in [2].
> 
> Why is Council intervention needed to abolish these policies? They're
> not binding.
> As far as I know, the games team has no special status so like any other
> project they can recommend whatever they want - nobody is obliged to
> listen (I certainly don't).

The games team believes that they're binding. In fact, I recall one of
the team members remarking explicitly that they're going to alter
ebuilds that were committed without their approval.

In fact, they did remove ebuilds from the tree in the past for this
reason [1].

[1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

[Rich Freeman]

On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny  wrote:
>
> The games team believes that they're binding. In fact, I recall one of
> the team members remarking explicitly that they're going to alter
> ebuilds that were committed without their approval.
>
> In fact, they did remove ebuilds from the tree in the past for this
> reason [1].
>
> [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0

This was 3 weeks ago, so certainly relevant.  Was this removal by
mutual agreement (ie the games team and maksbotan ?

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

[Ulrich Mueller]

> On Tue, 8 Jul 2014, Rich Freeman wrote:

> On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller  wrote:
>> The install locations (/usr/games, /usr/share/games, /var/games, etc.)
>> are specified by the FHS. So they're not entirely games team policy.

> I just checked some random packages on Debian and found that adherence
> to this path there is mixed.  I'd say the majority of packages I
> checked installed in /usr/games, but quite a few did not.  Many of the
> ones that tended to install there were games that probably predate the
> Linux kernel, but this was by no means exclusively the case.

> Their official policy says that games should go in /usr/games though.
> They also state "Each game decides on its own security policy."  They
> apparently only use a games group for things like high scores and save
> game dirs, and use sgid on the binary to accomplish this (minimizing
> its use in general).  (Note, I don't run Debian much, so this is the
> result of a quick scan of their policies and the real world may vary.)

It certainly differs between distros. Debian generally uses /usr/games
and has a games group for score files. Fedora has chosen to ignore the
FHS and installs everything in /usr/bin. IIUC, they also use an own
group for each game if it needs to write shared score files. [1]

Ulrich

[1] http://thread.gmane.org/gmane.comp.freedesktop.games/365


pgpXJ63S4Lv_h.pgp
Description: PGP signature

[gentoo-dev] Re: The request to abolish games team policy

[Michael Palimaka]

On 07/08/2014 09:38 PM, Michał Górny wrote:
> Dnia 2014-07-08, o godz. 20:52:49
> Michael Palimaka  napisał(a):
> 
>> On 07/08/2014 07:45 AM, Michał Górny wrote:
>>> I would like to ask the Council to abolish the following policies that
>>> have been established by the games team:
>>>
>>> 1. that the games team has authority over the actual maintainers
>>> on every game ebuild,
>>>
>>> 2. that every ebuild has to inherit games.eclass as the last eclass
>>> inherited [1], even if it actually increases the ebuild size rather
>>> than helping,
>>>
>>> 3. that games must adhere to games team-specific install locations
>>> and ownership rules, shortly listed in [2].
>>
>> Why is Council intervention needed to abolish these policies? They're
>> not binding.
>> As far as I know, the games team has no special status so like any other
>> project they can recommend whatever they want - nobody is obliged to
>> listen (I certainly don't).
> 
> The games team believes that they're binding. In fact, I recall one of
> the team members remarking explicitly that they're going to alter
> ebuilds that were committed without their approval.
> 
> In fact, they did remove ebuilds from the tree in the past for this
> reason [1].
> 
> [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0
> 

These sorts of actions are contrary to GLEP 39. I would encourage anyone
who is a victim of such behaviour to file a complaint with Comrel.

Whether we like it or not, the only projects with any kind of real
authority are those authorised by the Council. Whatever the games teams
happens to believe is irrelevant. They're free to petition the Council
to change reality of the situation if they don't like it.

Re: [gentoo-dev] Re: The request to abolish games team policy

[Ulrich Mueller]

> On Tue, 8 Jul 2014, Michał Górny wrote:

> In fact, they did remove ebuilds from the tree in the past for this
> reason [1].

Given that this was a live ebuild that failed to compile [2] and was
dumped onto the games team few weeks after it was committed to the
tree [3], I can even understand their reaction, in this particular
case.

Ulrich


[2] https://bugs.gentoo.org/show_bug.cgi?id=431552
[3] 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/metadata.xml?hideattic=0&r1=1.1&r2=1.2


pgpw_hLtRboPg.pgp
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

[Tomáš Chvátal]

2014-07-08 14:42 GMT+02:00 Ulrich Mueller :

> > On Tue, 8 Jul 2014, Michał Górny wrote:
>
> > In fact, they did remove ebuilds from the tree in the past for this
> > reason [1].
>
> Given that this was a live ebuild that failed to compile [2] and was
> dumped onto the games team few weeks after it was committed to the
> tree [3], I can even understand their reaction, in this particular
> case.
>

[2] Clear upstream bug, we remove live versions when from time to time
upstream break their repo? If you take look on 1.0 it IS almost the same
ebuild?
[3] I remved myself from maitnainership as I found out I don't have enought
time to work on stuff in Gentoo to keep myself only in office and to make
them working... So if they didn't want the live version it is perfectly
sane reasoning for pruning that before, but removing the 1.0 commited few
weeks ago it is just utter stupid approach and reason why I avoid to have
to touch anything with games team in Gentoo.

Tom

>
> Ulrich
>
>
> [2] https://bugs.gentoo.org/show_bug.cgi?id=431552
> [3]
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/metadata.xml?hideattic=0&r1=1.1&r2=1.2
>

Re: [gentoo-dev] Re: The request to abolish games team policy

[Michał Górny]

Dnia 2014-07-08, o godz. 08:10:14
Rich Freeman  napisał(a):

> On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny  wrote:
> >
> > The games team believes that they're binding. In fact, I recall one of
> > the team members remarking explicitly that they're going to alter
> > ebuilds that were committed without their approval.
> >
> > In fact, they did remove ebuilds from the tree in the past for this
> > reason [1].
> >
> > [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0
> 
> This was 3 weeks ago, so certainly relevant.  Was this removal by
> mutual agreement (ie the games team and maksbotan ?

I'm afraid not though I don't know for sure. Maks doesn't seem to be
around at the moment. Judging from the bug [1], I'd dare say
the proxied maintainer had to notice the disappearing ebuild file
himself.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=470188#c6

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

[Ulrich Mueller]

> On Tue, 8 Jul 2014, Tomáš Chvátal wrote:

> [3] I remved myself from maitnainership as I found out I don't have
> enought time to work on stuff in Gentoo to keep myself only in
> office and to make them working... So if they didn't want the live
> version it is perfectly sane reasoning for pruning that before, but
> removing the 1.0 commited few weeks ago it is just utter stupid
> approach and reason why I avoid to have to touch anything with games
> team in Gentoo.

I fear it's not such a simple black-and-white picture here. They have
removed a package belonging to the games herd (and not working at that
point), which I believe is in their right. Later this package was
resurrected, I suppose without talking to them. (?)

Not sure how I would react if I had removed a package from app-emacs,
and some developer would restore it, without consulting the emacs team
first. (Well, probably I'd have a serious word with the dev, at that
point ...)

Ulrich


pgpgthirFlmnq.pgp
Description: PGP signature

[gentoo-dev] Looking for alternative to RESTRICT=userpriv

[Michał Górny]

Hello, developers.

I've been doing some research wrt use of RESTRICT=userpriv [1] lately
and found out that most of the affected packages use it solely to gain
access to files or devices that are restricted to specific groups. I've
specifically noted three cases:

1) ebuilds using CUDA that needed to access /dev/nvidia* (restricted to
video group),

2) game ebuilds that needed to access game executables (restricted to
games group but hopefully subject to change),

3) qmail-related ebuilds that needed to access restricted files (no
details yet).

I believe that most (if not all) of uses of RESTRICT=userpriv are
overkill. It implies elevating privileges for the whole build process
while what's really needed is an access to a particular file or device,
or a capability of some kind for a single command execution.

I would therefore like to ask the Community for ideas on how
RESTRICT=userpriv could be effectively replaced by something safer.


I can enumerate the following possibilities:

a) explicitly requesting user to alter group membership for the build
user. This is already done in some of the CUDA ebuilds.

Advantages:

- limits elevated privileges to a particular group access,

- works now.

Disadvantages:

- requires manual intervention (we even can't properly name the user
  since there's no PMS function/variable to obtain it),

- increases privileges for all ebuilds rather than the one needing it.
  Developers using it will not get proper failures for ebuilds not
  having the check,

- doesn't cover other uses of FEATURES=userpriv.


b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups() to
transparently enable group membership for the build process.

Advantages:

- transparent, relatively simple.

Disadvantages:

- quite ugly name ;),

- doesn't cover other uses of FEATURES=userpriv.


c) 'esudo' helper [3]. This is a more generic form of (2), with support
for other potential privilege changes.

Advantages:

- allows to raise privileges precisely for one command,

- flexible -- may alter EUID, EGID, groups, capabilities.

Disadvantages:

- hard to implement -- especially if we want to make it capable of
  running bash functions.


What do you think? Do you have other ideas?


[1]:https://bugs.gentoo.org/show_bug.cgi?id=516568
[2]:https://bugs.gentoo.org/show_bug.cgi?id=516614
[3]:https://bugs.gentoo.org/show_bug.cgi?id=516616

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

[Rich Freeman]

On Tue, Jul 8, 2014 at 8:42 AM, Ulrich Mueller  wrote:
>> On Tue, 8 Jul 2014, Michał Górny wrote:
>
>> In fact, they did remove ebuilds from the tree in the past for this
>> reason [1].
>
> Given that this was a live ebuild that failed to compile [2] and was
> dumped onto the games team few weeks after it was committed to the
> tree [3], I can even understand their reaction, in this particular
> case.

I'm talking about the removal of 1.0 3 weeks ago, not the removal of
the live ebuild 2 years ago.

I don't know if the new maintainer was aware that the package had
previously been removed, but I'm not sure that it really matters.  As
long as the maintainer actually intended to maintain it I think that
matters more.  If the package had security issues/etc that would be a
different matter.

The 1.0 package was not a live ebuild, either.  Removing packages that
are live ebuilds that have no maintainer and a dying upstream is a bit
different from removing packages that are not live ebuilds that do
have a maintainer, even if upstream isn't necessarily better off.  In
any case, the maintainer certainly should have been consulted.

I'd encourage anybody re-introducing a package to also try to talk to
those involved with removing it, but it might not be obvious if an
obscure package had been removed two years in the past.

Uh, and what is up with games-strategy/openxcom and
games-engines/openxcom?  Was the re-introduction a dup?  If so, then
removal of it makes sense, though for that reason, and not simply
because it was added without talking to the games herd...

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

[Michał Górny]

Dnia 2014-07-08, o godz. 09:38:08
Rich Freeman  napisał(a):

> Uh, and what is up with games-strategy/openxcom and
> games-engines/openxcom?  Was the re-introduction a dup?  If so, then
> removal of it makes sense, though for that reason, and not simply
> because it was added without talking to the games herd...

Well, looking at that it seems that the games-engines/ version was
introduced 5 minutes after removing games-strategy/. So it was more of
a takeover + package move than removal.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: Looking for alternative to RESTRICT=userpriv

[Ulrich Mueller]

> On Tue, 8 Jul 2014, Michał Górny wrote:

> a) explicitly requesting user to alter group membership for the
> build user. This is already done in some of the CUDA ebuilds.

> [...]

This doesn't work out of the box for users, therefore it is not really
a solution.

> b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups()
> to transparently enable group membership for the build process.

> Advantages:

> - transparent, relatively simple.

> Disadvantages:

> - quite ugly name ;),

Certainly this can be changed. :)

> - doesn't cover other uses of FEATURES=userpriv.

Which ones? Are there examples for such uses in the Portage tree?

> c) 'esudo' helper [3]. This is a more generic form of (2), with
> support for other potential privilege changes.

> [...]

> Disadvantages:

> - hard to implement -- especially if we want to make it capable of
>   running bash functions.

Any idea how to implement it? Does it imply adding app-admin/sudo to
the system set?

> What do you think? Do you have other ideas?

Looking at the bugs that you have filed, it looks like most ebuilds
using userpriv restriction could be fixed, without any additional
support added to the package manager.

How many ebuilds will be left, after doing these fixes? Is it really
worth the effort then?

Ulrich


pgpJHuxhCGDUf.pgp
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

[Maxim Koltsov]

2014-07-08 16:10 GMT+04:00 Rich Freeman :

> On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny  wrote:
> >
> > The games team believes that they're binding. In fact, I recall one of
> > the team members remarking explicitly that they're going to alter
> > ebuilds that were committed without their approval.
> >
> > In fact, they did remove ebuilds from the tree in the past for this
> > reason [1].
> >
> > [1]:
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0
>
> This was 3 weeks ago, so certainly relevant.  Was this removal by
> mutual agreement (ie the games team and maksbotan ?
>
> Rich
>
>
No, I was not notified beforehand (or failed to recieve such notification,
it does not matter now). This was a proxied commit, I did a usual check of
the ebuild and found no problems. I admit that the ebuild was
not-so-compliant to games herd rules, though. Still, immediate removal
without notification and/or discussion did annoy me.
BTW, I fail to see the reason of move to games-engines, but that's another
issue.

-- 
Regards, Maxim.

Re: [gentoo-dev] Re: The request to abolish games team policy

[Samuli Suominen]

On 08/07/14 17:18, Maxim Koltsov wrote:
>
>
>
> 2014-07-08 16:10 GMT+04:00 Rich Freeman  >:
>
> On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny  > wrote:
> >
> > The games team believes that they're binding. In fact, I recall
> one of
> > the team members remarking explicitly that they're going to alter
> > ebuilds that were committed without their approval.
> >
> > In fact, they did remove ebuilds from the tree in the past for this
> > reason [1].
> >
> >
> 
> [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0
>
> This was 3 weeks ago, so certainly relevant.  Was this removal by
> mutual agreement (ie the games team and maksbotan ?
>
> Rich
>
>
> No, I was not notified beforehand (or failed to recieve such
> notification, it does not matter now). This was a proxied commit, I
> did a usual check of the ebuild and found no problems. I admit that
> the ebuild was not-so-compliant to games herd rules, though. Still,
> immediate removal without notification and/or discussion did annoy me.
> BTW, I fail to see the reason of move to games-engines, but that's
> another issue.
>
> -- 
> Regards, Maxim.

Did you get the ebuild reviewed and accepted for committing at
#gentoo-games as per existing guidelines[1]?
If you didn't, then you propably managed to annoy them first, and the
outcome was expected (as in, the missing work
was done for you, with best intentions)
I've never had any issues with getting games ebuilds reviewed at
#gentoo-games and I've committed dozen(s) of
games to tree.
I've been on the channel, almost always I'm online, I haven't seen
people getting ignored there who have proper
initial work done first (if the ebuild is in a shape you'd have to
rewrite every second line, you might get ignored,
and I find that to be reasonable, since we are all volunteers, afterall)

[1] http://dev.gentoo.org/~vapier/i-wanna-be-in-the-games-herd.html

And some personal thoughts about the initial proposal...
I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
and 2. should definately
stay as is. Since games ebuilds are low maintenance, there is no intrest
in getting dozens of 'eclass porting
bugs', which is why inheriting games last prevents future breakage as
well as ensure the eclasses
exported phases are respected.
It seems to me like people aren't making the effort of joining to the
team and meeting the high quality
ebuild syntax they've kept up...

- Samuli

[gentoo-dev] Re: The request to abolish games team policy

[Michael Palimaka]

On 07/09/2014 01:22 AM, Samuli Suominen wrote:
> And some personal thoughts about the initial proposal...
> I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
> and 2. should definately
> stay as is.
What authority does the game team have over anything? Did it get special
blessing from the Council? Isn't it just another regular project as per
GLEP 39?

Re: [gentoo-dev] Re: The request to abolish games team policy

[Rich Freeman]

On Tue, Jul 8, 2014 at 12:17 PM, Michael Palimaka  wrote:
> On 07/09/2014 01:22 AM, Samuli Suominen wrote:
>> And some personal thoughts about the initial proposal...
>> I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
>> and 2. should definately
>> stay as is.
> What authority does the game team have over anything? Did it get special
> blessing from the Council? Isn't it just another regular project as per
> GLEP 39?
>

While I tend to agree with the sentiment, and it may not be productive
to try to turn this into a bunch of rules, it is beneficial to have
guidelines/etc managed by projects in general, and to have maintainers
generally try to follow them.

So, if you're using the multilib eclass in your ebuild then it only
make sense to coordinate with the project that manages that.  It isn't
so much about following rules as it just makes sense to not have
everything randomly break anytime somebody changes something.

If the games team is active and wants to help steer contributions that
isn't a bad thing.  I'd suggest a bit more finesse though - they can
at least talk to maintainers before doing a package move.

I've managed exactly one game package and I can't say that working
with the games herd has ever been a problem.  For the most part
they're fairly hands-off as long as you follow their rules.

That said, if anybody wants to be able to tell others what they can
and can't do then they should be prepared to have their rules
bikesheded in public from time to time.  That's just the price of
fame, and if all games are supposed to follow the game project rules,
then those rules are perfectly good cannon fodder for -dev, whether it
gets escalated to council or not.  :)

Rich

Re: [gentoo-dev] Re: The request to abolish games team policy

[hasufell]

Samuli Suominen:
> 
> It seems to me like people aren't making the effort of joining to the
> team and meeting the high quality
> ebuild syntax they've kept up...
> 

There is no games _team_. There is Mr_Bones_ (and I have learned a lot
from him and am able to collaborate with him).

And that is that.

There is no active lead and the lead ignores joining requests and
doesn't care about non-trivial games libraries like SDL2.

So, it really isn't as you say.

[gentoo-dev] Re: The request to abolish games team policy

[Michael Palimaka]

On 07/09/2014 02:58 AM, Rich Freeman wrote:
> On Tue, Jul 8, 2014 at 12:17 PM, Michael Palimaka  
> wrote:
>> On 07/09/2014 01:22 AM, Samuli Suominen wrote:
>>> And some personal thoughts about the initial proposal...
>>> I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
>>> and 2. should definately
>>> stay as is.
>> What authority does the game team have over anything? Did it get special
>> blessing from the Council? Isn't it just another regular project as per
>> GLEP 39?
>>
> 
> While I tend to agree with the sentiment, and it may not be productive
> to try to turn this into a bunch of rules, it is beneficial to have
> guidelines/etc managed by projects in general, and to have maintainers
> generally try to follow them.
Of course. I'm not at all suggesting flouting guidelines for the sake of it.

In general the guidelines of multilib/python/Gnome/KDE/whatever are
followed because of mutual respect between the projects and maintainers.
I follow the guidelines of the python project because I respect their
knowledge and experience in the matter. Conversely, the python project
respects my role as a maintainer and doesn't needlessly interfere.

This is not true of the games team, which attempts to dominate game
packages for no discernable reason. If it behaved more like the other
projects issuing guidelines we wouldn't he having this discussion.

"My way or the highway" is not how to achieve a better Gentoo.

Re: [gentoo-dev] Re: The request to abolish games team policy

[Pacho Ramos]

El mar, 08-07-2014 a las 17:15 +, hasufell escribió:
> Samuli Suominen:
> > 
> > It seems to me like people aren't making the effort of joining to the
> > team and meeting the high quality
> > ebuild syntax they've kept up...
> > 
> 
> There is no games _team_. There is Mr_Bones_ (and I have learned a lot
> from him and am able to collaborate with him).
> 
> And that is that.
> 
> There is no active lead and the lead ignores joining requests and
> doesn't care about non-trivial games libraries like SDL2.
> 
> So, it really isn't as you say.
> 

What kind of games packages does he want to maintain in a "strictly"
way? Maybe one way to cooperate would be to have two herds:
- games-base (or similar) -> the more "stricter" and the one Mr_Bones
would likely still prefer to handle himself. It would take care of
central libs related with games
- games-extra (or...) -> a bit less strict in terms of accepting other
team members or similar.

Anyway, hopefully Mr. Bones will reply and explain a bit his position :)

Best regards

Re: [gentoo-dev] Re: The request to abolish games team policy

[hasufell]

Pacho Ramos:
> 
> What kind of games packages does he want to maintain in a "strictly"
> way? Maybe one way to cooperate would be to have two herds:
> - games-base (or similar) -> the more "stricter" and the one Mr_Bones
> would likely still prefer to handle himself. It would take care of
> central libs related with games
> - games-extra (or...) -> a bit less strict in terms of accepting other
> team members or similar.
> 

I don't see how that is a solution. Mr_Bones_ is collaborative if you
bother him long enough on IRC. That's not the thing.

I meant that there is no _team_. And there seems to be very little
interest to improve that.

After all, vapier is the lead. And the lead is responsible for managing
the team.

I could make a list of things that didn't get much attention from him:
* joining requests
* review requests for non-trivial libraries like SDL2
* review requests for games.eclass changes
* review request for games-bin.eclass
* RFC about an official games overlay
* growing number of games overlays which means people stopped caring to
contribute via bugzilla (yes, that's a problem the project has to fix)
* growing number of developers who are uninterested to work with the
team, probably because of lack of communication (a single person on IRC
is not enough, mails to games@ are widely ignored)
...

Vapier responds when he feels like it, when something catches his
attention. But he doesn't follow games stuff on a regular basis anymore,
probably because his focus has shifted. And that happens, sure.

Therefor I'm not really interested in decisive council intervention
here. We already did that and it failed, IMO.

But I'd appreciate if the games project can:
* reconsider who currently has the time and capacity to be an
appropriate lead
* make the team more open to collaboration from devs
* make the team more open to collaboration from users (e.g. via an
official games overlay on github... bugzilla sucks)
* respond to joining requests
* discuss possible solutions to known eclass problems openly

If they miss the opportunity to improve these things, then we will
likely see that more people will start to ignore the games project. And
that's an even worse situation.

Anyway, this thread certainly has several points. One is just the
eclass, the other is the project behind it. I'd suggest to focus on the
latter first, maybe the former will be easier to fix then instead of
forcing anarchy-rage by council decision or something like that.

[gentoo-dev] splitting out arm keywords

[Matthew Thode]

arm has a historical problem with stabilization, while keywording
doesn't require access to all arm sub-arches the problem with the
stabilization slowness causes running a full ~arm to become hard.  By
that I mean that if someone keywords something for arm because it works
on armv7 and I run ~arm because stabilization takes forever then my
system may break because of both non-stabilized packages and because I
could be running armv6.

In any case I propose splitting out arm into armv4, armv5, armv6 and
armv7.  armv8 seems to be here already as arm64.

I think this would be beneficial because of not all developers that want
to help with arm have or what all the sub-arches necessary.  It also
allows us to move faster on stabilization because most of us have access
to armv7 a bit easier.  This would take some pressure off of the people
doing stabilization for older sub-arches, but not much.


Some issues that need solving are as follows.

[hard|soft]float differences.  what stabilization means would need to be
clarified a bit here.

additional overhead of multiple arm teams


Might be missing some points, but that's the main stuff I think

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: The request to abolish games team policy

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/08/2014 08:32 AM, Ulrich Mueller wrote:
>> On Tue, 8 Jul 2014, Rich Freeman wrote:
> 
>> On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller 
>> wrote:
>>> The install locations (/usr/games, /usr/share/games,
>>> /var/games, etc.) are specified by the FHS. So they're not
>>> entirely games team policy.
> 
>> I just checked some random packages on Debian and found that
>> adherence to this path there is mixed.  I'd say the majority of
>> packages I checked installed in /usr/games, but quite a few did
>> not.  Many of the ones that tended to install there were games
>> that probably predate the Linux kernel, but this was by no means
>> exclusively the case.
> 
>> Their official policy says that games should go in /usr/games
>> though. They also state "Each game decides on its own security
>> policy."  They apparently only use a games group for things like
>> high scores and save game dirs, and use sgid on the binary to
>> accomplish this (minimizing its use in general).  (Note, I don't
>> run Debian much, so this is the result of a quick scan of their
>> policies and the real world may vary.)
> 
> It certainly differs between distros. Debian generally uses
> /usr/games and has a games group for score files. Fedora has chosen
> to ignore the FHS and installs everything in /usr/bin. IIUC, they
> also use an own group for each game if it needs to write shared
> score files. [1]
> 
> Ulrich
> 
> [1] http://thread.gmane.org/gmane.comp.freedesktop.games/365
> 

Just to clarify, the current Gentoo policy is that game executables go
in /usr/games/bin and libraries go in /usr/games/$(get_libdir).
Debian policy follows FHS in that games binaries go directly in
/usr/games and games libraries go in the same directory as other
libraries.

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTvKBxAAoJELHSF2kinlg4y/kP/jj6wkESt7cXnj+MdgIcdYQd
2DSz1LQID4GyS4+Zkc8oIIfQCjWVBp4ZL3biEPDi2wWoF8gmsQPcnzru0/XlLwlb
+0S4NfrsA4I53DUztDV1XW4Wsi1VxYF2RzCo/W+S7ZdzNceAkRcvFt9hEUhNlFnu
6DCw/yf8dHC3IkblU3Bs4ZYltkVQbCIuc02RYyT8UYKW72h5vbW0BJg032WYJkA5
gYW0RSWplv++z1ngeI+7LJ/bAJzD9wwriSY3ilBknrBNlR1AI2/S3EdQsQUyJt8I
QrlweD7KIlhjj1Rb7zet04FMyLfoVtD0h2Gbyvht2l6ZQLvV8aIuO9VwWdaST2fF
45UkGKIMYt3zU4qH1l4qo5IuYYSkPcSmzXAdCG8GlKmWShI3heQcKEafH2kR35e7
os7D5z4DofzpwRgjd4KKebG3v0q3NLUyKhrlik2dTSO+jPOYGj45Ow1o83Up5U6V
9xB6PilLx9SoiVvU1prwG3WGd1s9J3YGq4JWWzxm9mGGQThdrvQUvLFNoIO7zOWF
l0Dp4IMLnfrmGa9RWyzaBbYMZMK693novbkbr7yW+PFaBUjfKEsxasp9JHTwBDcF
jW2iAf/a1JraP1APbDp9gYCXHfDO9wNXwzI3wyT5QvLkyzkLBUkPg+3gcdIDFgbM
ugURcg6HIZ1bd4vQED6U
=RdNt
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: The request to abolish games team policy

[Samuli Suominen]

On 08/07/14 19:17, Michael Palimaka wrote:
> On 07/09/2014 01:22 AM, Samuli Suominen wrote:
>> And some personal thoughts about the initial proposal...
>> I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
>> and 2. should definately
>> stay as is.
> What authority does the game team have over anything? Did it get special
> blessing from the Council? Isn't it just another regular project as per
> GLEP 39?
>
>
>

Not everything we have had since-always-standing is documented,
unfortunately -- games has always been special from others
Still, even if it's undocumented, it doesn't mean it doesn't exist

It's like the amd64/x86 stabilization exception that everyone
who can test them can mark them, "everyone" knew it existed
but it wasn't documented properly

Sure, we should drive to getting everything documented, to avoid
thesekind of confusions with newer people...

- Samuli

Re: [gentoo-dev] Re: The request to abolish games team policy

[Tom Wijsman]

On Wed, 09 Jul 2014 06:55:54 +0300
Samuli Suominen  wrote:

> 
> On 08/07/14 19:17, Michael Palimaka wrote:
> > On 07/09/2014 01:22 AM, Samuli Suominen wrote:
> >> And some personal thoughts about the initial proposal...
> >> I don't care about the suggestion 3. in mgorny's proposal at all,
> >> but 1. and 2. should definately
> >> stay as is.
> > What authority does the game team have over anything? Did it get
> > special blessing from the Council? Isn't it just another regular
> > project as per GLEP 39?
> 
> Not everything we have had since-always-standing is documented,
> unfortunately -- games has always been special from others
> Still, even if it's undocumented, it doesn't mean it doesn't exist

If it would have special blessing, it would be documented in one of the
Council logs and/or summaries; that is about the only way it can receive
it, apart from a large scale thread showing the same wide agreement.

> [...] confusions with newer people...

Ironically; my first Portage tree action "add a directory" got a "don't
throw [expletive] into [games category]" reply, before adding the ebuild.

One really can't expect new people to start to address a team like
that prior to addition; I've assumed for some time that contacting the
teams is a necessity before addition of an ebuild, but that quickly
turned out to be false for most if not all other teams.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The request to abolish games team policy

[Samuli Suominen]

On 09/07/14 07:24, Tom Wijsman wrote:
>> [...] confusions with newer people...
> Ironically; my first Portage tree action "add a directory" got a "don't
> throw [expletive] into [games category]" reply, before adding the ebuild.
>
> One really can't expect new people to start to address a team like
> that prior to addition; I've assumed for some time that contacting the
> teams is a necessity before addition of an ebuild, but that quickly
> turned out to be false for most if not all other teams.
>

Well, I consider gnome-base/ to be gnome@g.o's "territory" in sense that
I'd contact the team prior to adding a ebuild there
Likewise I consider both, xfce-base/ and xfce-extra/ as well as anything
with xfce@g.o in metadata.xml to be xfce@g.o's "territory" in sense that
I'd be slightly annoyed if someone adds/modifies/... an Xfce ebuild without
consulting me (or angelos). But, if it's done properly, like hasufell added
properly added xfce4-whiskermenu-plugin to xfce-extra/, I'll stay quiet,
because it wouldn't achieve anything to complain about something you
would have added _exactly_ the same way line-by-line
Likewise I consider kde-base/ to be kde@g.o's "territory"

And I'm sure the tree has more of these...

Re: [gentoo-dev] Re: The request to abolish games team policy

[Rich Freeman]

On Tue, Jul 8, 2014 at 11:55 PM, Samuli Suominen  wrote:
>
> On 08/07/14 19:17, Michael Palimaka wrote:
>> On 07/09/2014 01:22 AM, Samuli Suominen wrote:
>>> And some personal thoughts about the initial proposal...
>>> I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
>>> and 2. should definately
>>> stay as is.
>> What authority does the game team have over anything? Did it get special
>> blessing from the Council? Isn't it just another regular project as per
>> GLEP 39?
>
> Not everything we have had since-always-standing is documented,
> unfortunately -- games has always been special from others
> Still, even if it's undocumented, it doesn't mean it doesn't exist

Figuring out whether it was ever supposed to have that kind of
authority isn't quite as important as figuring out whether we still
want it to.

Other types of packages seem to get by just fine without them (even
system packages).  Why treat games differently than other types of
packages?  We don't use /usr/X11R6 despite that being in FHS right
alongside /usr/games.

If we do want it to have special authority then governance matters
more.  However, it would be far simpler to just treat games the way we
treat everything else.  Is there a reason not to?

Rich