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

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

[Michał Górny]

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

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

More specifically, I would like the games to be 'freed' from the games
team monopoly and treated like every other package. More specifically,
I believe that:

i. games should be maintained by their respective maintainers,
and games team (if any) should help rather than overriding their
decisions,

ii. that the games.eclass should be deprecated and likely disabled
in the next EAPI since wrapping phases and helper functions makes it
close to base.eclass in design,

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.


I feel like the games team is more focused on keeping the 'status
quo' than working on improving the experience of Gentoo users.
The problems with current game install design have been pointed out
multiple times, and the suggestions were either ignored by the team or
refused, sometimes with strong words. In fact, the team's own decisions
are creating further issues that they afterwards need to work around.

The most notable issues with the specific use of games group include:

a. nethack security issue [3] that is purely Gentoo-specific, and is
open with no action from games since 2006,

b. multiple game ebuilds being unable to access files installed by
other game ebuilds that are worked around with dangerous
RESTRICT=userpriv [4,5,6].

Moreover, the eclass is purely suited for autotools-based ebuilds.
The policy enforced by the team makes it very hard to create proper
ebuilds for other build systems, often requiring redeclaration of all
phase functions (to restore the proper eclass) and heavy patching of
install locations.


The number of inconveniences, lack of replies (lack of time?) has
resulted in multiple games being spread throughout various overlays.
I think the gamerlay project [7] is most notable. Sadly, this results
in even worse quality of games in Gentoo.

I believe that the policy needs to change. While I respect the members
of games team, I don't think they should be allowed to prevent other
developers from committing game ebuilds, and I don't agree with keeping
the 'status quo' of games.eclass for the sake of keeping it while
the issues outweigh the benefit (it is actually negotiable whether
there's any).

I would like to ask the Community for their opinion on this issue.
When the new Council term starts, I will add the issue to the agenda.
Unless the games team decides to give up their policies and allow
developers to work on cleaning up games before that.


[1]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap3
[2]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap4
[3]:https://bugs.gentoo.org/show_bug.cgi?id=125902
[4]:https://bugs.gentoo.org/show_bug.cgi?id=112898
[5]:https://bugs.gentoo.org/show_bug.cgi?id=419331
[6]:https://bugs.gentoo.org/show_bug.cgi?id=516576
[7]:https://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary

-- 
Best regards,
Michał Górny

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

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

[James Potts]

On Mon, Jul 7, 2014 at 4:45 PM, Michał Górny <mgorny@gentoo.org> 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].
>
> More specifically, I would like the games to be 'freed' from the games
> team monopoly and treated like every other package. More specifically,
> I believe that:
>
> i. games should be maintained by their respective maintainers,
> and games team (if any) should help rather than overriding their
> decisions,
>
> ii. that the games.eclass should be deprecated and likely disabled
> in the next EAPI since wrapping phases and helper functions makes it
> close to base.eclass in design,
>
> 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.
>
>
> I feel like the games team is more focused on keeping the 'status
> quo' than working on improving the experience of Gentoo users.
> The problems with current game install design have been pointed out
> multiple times, and the suggestions were either ignored by the team or
> refused, sometimes with strong words. In fact, the team's own decisions
> are creating further issues that they afterwards need to work around.
>
> The most notable issues with the specific use of games group include:
>
> a. nethack security issue [3] that is purely Gentoo-specific, and is
> open with no action from games since 2006,
>
> b. multiple game ebuilds being unable to access files installed by
> other game ebuilds that are worked around with dangerous
> RESTRICT=userpriv [4,5,6].
>
> Moreover, the eclass is purely suited for autotools-based ebuilds.
> The policy enforced by the team makes it very hard to create proper
> ebuilds for other build systems, often requiring redeclaration of all
> phase functions (to restore the proper eclass) and heavy patching of
> install locations.
>
>
> The number of inconveniences, lack of replies (lack of time?) has
> resulted in multiple games being spread throughout various overlays.
> I think the gamerlay project [7] is most notable. Sadly, this results
> in even worse quality of games in Gentoo.
>
> I believe that the policy needs to change. While I respect the members
> of games team, I don't think they should be allowed to prevent other
> developers from committing game ebuilds, and I don't agree with keeping
> the 'status quo' of games.eclass for the sake of keeping it while
> the issues outweigh the benefit (it is actually negotiable whether
> there's any).
>
> I would like to ask the Community for their opinion on this issue.
> When the new Council term starts, I will add the issue to the agenda.
> Unless the games team decides to give up their policies and allow
> developers to work on cleaning up games before that.
>
>
> [1]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap3
> [2]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap4
> [3]:https://bugs.gentoo.org/show_bug.cgi?id=125902
> [4]:https://bugs.gentoo.org/show_bug.cgi?id=112898
> [5]:https://bugs.gentoo.org/show_bug.cgi?id=419331
> [6]:https://bugs.gentoo.org/show_bug.cgi?id=516576
> [7]:https://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary
>
> --
> Best regards,
> Michał Górny

Here's my non-developer point-of-view:

I agree with this - games are lagging way behind in gentoo compared to
other distributions, and this heavy-handed super-maintainership by the
games herd explains why.  If a person wants his game to be
co-maintained by the games herd, fine, they have to follow the rules
of the games herd, but being in the games herd should be an option,
not a requirement for a game to be in the tree.  Lets let the people
who want to maintain game ebuilds maintain them, governed by the same
rules as all other ebuilds, regardless of herd status.

I also agree that the games group needs to go, for the most part -
users shouldn't have to be in it to play games (they shouldn't be in
it at all, but that's a different story) - that's a dated policy that
likely comes from mainframe unix environments and really doesn't
belong on a modern linux desktop or server, so it just winds up
confusing and/or annoying people.

--James

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

[Eray Aslan]

On Mon, Jul 07, 2014 at 11:45:02PM +0200, Michał Górny wrote:
> I would like to ask the Council to abolish the following policies that
> have been established by the games team:

Why?  What's the use case?  Or in other words, what has ticked you off
to request the abolishment of status-quo?

> The most notable issues with the specific use of games group include:

While undoubtedly serious, I do not feel that these issues call for such
a radical change.  What's the background for this change request?  Is
this a multilib issue?

Need more info.  Thanks.

-- 
Eray

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

[Ulrich Mueller]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller <ulm@gentoo.org> 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 <kensington@gentoo.org> 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]

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

Dnia 2014-07-08, o godz. 20:52:49
Michael Palimaka <kensington@gentoo.org> 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

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

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

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

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

> On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller <ulm@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Tomáš Chvátal]

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

2014-07-08 14:42 GMT+02:00 Ulrich Mueller <ulm@gentoo.org>:

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

[-- Attachment #2: Type: text/html, Size: 1986 bytes --]

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

[Michał Górny]

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

Dnia 2014-07-08, o godz. 08:10:14
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny <mgorny@gentoo.org> 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

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

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

[Ulrich Mueller]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Tue, Jul 8, 2014 at 8:42 AM, Ulrich Mueller <ulm@gentoo.org> 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]

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

Dnia 2014-07-08, o godz. 09:38:08
Rich Freeman <rich0@gentoo.org> 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

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

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

[Maxim Koltsov]

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

2014-07-08 16:10 GMT+04:00 Rich Freeman <rich0@gentoo.org>:

> On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny <mgorny@gentoo.org> 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.

[-- Attachment #2: Type: text/html, Size: 1821 bytes --]

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 <rich0@gentoo.org
> <mailto:rich0@gentoo.org>>:
>
>     On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny <mgorny@gentoo.org
>     <mailto:mgorny@gentoo.org>> 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 <kensington@gentoo.org> 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 <kensington@gentoo.org> 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 +0000, 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] 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 <ulm@gentoo.org>
>> 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]

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

On Wed, 09 Jul 2014 06:55:54 +0300
Samuli Suominen <ssuominen@gentoo.org> 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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

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

[Ulrich Mueller]

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

>>>>> On Tue, 08 Jul 2014, Jonathan Callen wrote:

> On 07/08/2014 08:32 AM, Ulrich Mueller wrote:
>> 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]
>> 
>> [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.

I see. So Gentoo policy differs from FHS (and from other major
distros).

FHS also says that static data files should go in /usr/share/games,
whereas on my system I see both /usr/share/games and /usr/games/share.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Wed, Jul 9, 2014 at 2:06 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>
> 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"

If we were talking about a core games-base set of libs that lots of
games depended on I think most would see the analogy here.

However, anybody can maintain a random package that uses libkde
without any kind of blessing from the KDE team, and they don't have to
stick it in a kde category.  These teams don't claim ownership of
entire genres of applications.  They're taking care of the core
desktop environment because something like KDE could really be viewed
as one gigantic package that is modularly installable - historically
it wasn't even modular at all.  If there is some app that installs a
plasma widget that isn't bundled with the KDE project, why shouldn't
any maintainer be able to install it?  It would behoove them to follow
the KDE guidelines mainly so that they don't have to fix their package
the next time there is a KDE bump.  Likewise you probably don't need
to twist arms to get people to use the systemd eclass to install unit
files since it just makes your life easier - they systemd team won't
rename your package if it installs a unit and they don't like the
category you chose.

Games is a bit different in that we basically have policies that apply
to a genre of applications.  A policy for packages that use SDL
designed around the technical requirements of maintaining SDL makes
more sense than general policies around packages that are "fun."  Heck
- you'd be hard-pressed to come up with an objective definition for
what is and isn't a game in the first place, which is why you have
stuff like "fortune" in the games category.  Oddly enough you don't
have to be in the games group to run it.

Rich

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

[Sergey Popov]

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

09.07.2014 03:08, 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.
> 

While i do not agree with some summary, that you pointed here, it does
not really matter, because the most of your discussed things is really true.

I was the one, who tried to join to Games team(it was around 1,5 years
ago). And i have failed to get any answer from vapier.

But, honesly, i can not see problem in this. We have similar problem in
ARM team, which was fixed by electing new leads by those, who really did
most of ARM stuff AND actively responds on e-mails. And yes, previous
lead was vapier.

I do not want to say that vapier is not doing anything, it would be
terrible lie.

But project lead should actively responds to the requests. no matter how
big his contribution is in terms of code/ebuilds/etc. If it does not
reply, the whole progress can be stopped: if there is no way to join the
project without lead approval(and lead does not responding) - we have no
new manpower. Older developers has been retired and still no new manpower.

And then - project dies. Let's try to save Gentoo Games from this!

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

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

[Vadim A. Misbakh-Soloviov]

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

В письме от Вт, 8 июля 2014 18:22:50 пользователь 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...

Samuli! With all my respect to you personally, please, don't tell anything 
about "high quality" of ebuilds syntax by the games team. Please.

-- 
Best regsrds,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Rich Freeman]

On Wed, Jul 9, 2014 at 11:28 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
> But, honesly, i can not see problem in this. We have similar problem in
> ARM team, which was fixed by electing new leads by those, who really did
> most of ARM stuff AND actively responds on e-mails.

Doing this and giving the games team a chance to set its own destiny
seems like a reasonable first step. This should include their
considering Michał's proposals and reacting.  Then the community can
gauge whether intervention "from above" is still needed.

Does anybody want to step up as somebody who wants to join the team
and be the point of contact for anybody else who wants to join in
(basically an interim lead only for the purpose of organizing a
meeting and electing a lead including of course all existing team
members)?  Devs can probably add themselves to the alias already, and
if non-devs want to participate they can reach out to the coordinator
to be added.

If anybody has an objection to the influx then somebody can deal with
that (new council if worst comes to worst), but otherwise this should
give the team a shot in the arm.

I think it is best to just look forward, of course accepting input
from what was done in the past so as to learn from it.

Just my personal suggestion, but unless somebody really objects I
don't think it needs anybody's blessing.  By all means speak up if you
think it is a terrible idea.

Rich

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

[Samuli Suominen]

On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote:
> В письме от Вт, 8 июля 2014 18:22:50 пользователь 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...
> Samuli! With all my respect to you personally, please, don't tell anything 
> about "high quality" of ebuilds syntax by the games team. Please.
>

There are open bugs (non-ebuild bugs), sure
There are sometimes wrong dependencies in old binary-only games which
require special CD-ROM or other distfile, because that's
when we rely upon users to report the dependencies

But, the ebuild syntax is good as it's in eg. base-system, toolchain
And games ebuilds are nice examples for people learning to write ebuilds

So, don't know what you are referring to...

- Samuli

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

[Tom Wijsman]

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

On Wed, 09 Jul 2014 09:06:11 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

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

True, but as rich0 has written a detailed reply about is that it
isn't about the categories; it's rather just that it becomes more
noticeable when it is committed to such, that doesn't imply that all
GNOME-ly packages in other categories are suddenly GNOME team reviewed.

There's like for example an "unofficial" MATE display manager floating
around, I think it's mdm in short; I wouldn't care if someone added it
to the Portage tree, as long as it isn't given an "official" appearance.
It's not like I'll be thoroughly reviewing it as a MATE maintainer...

Hence, given I assume my ebuilds are of sufficiently high quality and
therefore stable candidates, I rarely contact team leads; for those
that are of worse quality, I'll contact them soon enough as I'll
probably do need the help and/or review then due to lack of knowledge.

That makes me think that it becomes odd when such stable candidates
suddenly receive non maintainer commits or removals as I've read here.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Tom Wijsman]

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

On Wed, 09 Jul 2014 21:01:02 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> 
> On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote:
> > В письме от Вт, 8 июля 2014 18:22:50 пользователь 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...
> > Samuli! With all my respect to you personally, please, don't tell
> > anything about "high quality" of ebuilds syntax by the games team.
> > Please.
> >
> 
> There are open bugs (non-ebuild bugs), sure
> There are sometimes wrong dependencies in old binary-only games which
> require special CD-ROM or other distfile, because that's
> when we rely upon users to report the dependencies
> 
> But, the ebuild syntax is good as it's in eg. base-system, toolchain
> And games ebuilds are nice examples for people learning to write
> ebuilds
> 
> So, don't know what you are referring to...

The coin has two sides; while you may shine a good light on the ebuilds
in the Portage tree, it may shine a bad light on those in game overlays
as I think this comparison was made somewhere earlier in this thread.

From what I know, people appreciate those game overlays; so, while I'm
not suggesting that you do shine such light, I'd just like to ask like
mva for everyone to stop making such comparisons and/or quality checks.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[hasufell]

Samuli Suominen:
> 
> On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote:
>> В письме от Вт, 8 июля 2014 18:22:50 пользователь 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...
>> Samuli! With all my respect to you personally, please, don't tell anything 
>> about "high quality" of ebuilds syntax by the games team. Please.
>>
> 
> There are open bugs (non-ebuild bugs), sure
> There are sometimes wrong dependencies in old binary-only games which
> require special CD-ROM or other distfile, because that's
> when we rely upon users to report the dependencies
> 
> But, the ebuild syntax is good as it's in eg. base-system, toolchain
> And games ebuilds are nice examples for people learning to write ebuilds
> 
> So, don't know what you are referring to...
> 
> - Samuli
> 

boooooooooo

I dont see any cocin brooooo let us do a dancee ::Dd


damce damve dance

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

[hasufell]

Samuli Suominen:
> 
> On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote:
>> В письме от Вт, 8 июля 2014 18:22:50 пользователь 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...
>> Samuli! With all my respect to you personally, please, don't tell anything 
>> about "high quality" of ebuilds syntax by the games team. Please.
>>
> 
> There are open bugs (non-ebuild bugs), sure
> There are sometimes wrong dependencies in old binary-only games which
> require special CD-ROM or other distfile, because that's
> when we rely upon users to report the dependencies
> 
> But, the ebuild syntax is good as it's in eg. base-system, toolchain
> And games ebuilds are nice examples for people learning to write ebuilds
> 
> So, don't know what you are referring to...
> 
> - Samuli
> 

I think my mail client is broken, so the previous mail had some
unrelated strings.

Anyway, I agree that there is a high standard and it might be harder for
inexperienced contributors to get their first games ebuilds in shape,
but it is doable.

However, basically having only a single person that actively does such
reviews + no official overlay makes it hard for contributors.

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

[Rich Freeman]

On Fri, Jul 11, 2014 at 12:24 PM, hasufell <hasufell@gentoo.org> wrote:
>
> However, basically having only a single person that actively does such
> reviews + no official overlay makes it hard for contributors.
>

Is there still anybody left who wants to actually join the games team?
 I suggested that somebody step up who was interested in a previous
email and did not get any takers.  There isn't much point in trying to
break the logjam of people joining if nobody wants to join.

I don't have a personal interest in joining the team, but if there are
people around who want to join the team but don't want to deal with
trying to get the team re-organized I don't mind just helping to kick
things off.  That said, somebody will have to be the lead (and it
could be the same as the current lead if the team so decides).

So, if you are just shy about posting publicly feel free to email me
with your interest in joining the games project and I'll see if I can
help mediate a little.

Again, this is just personal initiative and my main interest is trying
to constitute a games project that runs itself and doesn't need order
imposed from above.  If I run into strong objections/etc I'll turn it
over to the next Council to deal with whether that includes me or not.
In the absence of objection, however (and nobody has raised any yet),
I don't see any reason that we can't try to add more members to the
team.

Rich

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

[Denis Dupeyron]

Please do not take this personally.

I honestly wonder what all the fuss is about. There are a few games
I've helped with over the years and I've never had any trouble at all
having my stuff reviewed and accepted. And I'm a lousy ebuild writer.
Every time I'd suggest a fix, bump, or new package, and I came with an
ebuild, I would get constructive criticism and I could then commit it
myself. Not one single time did I get a "no". Not once.

You had a fix and it was refused? Have you ever considered you may
have been doing it wrong? I understand having to have your code
reviewed and accepted sounds like an insult to a rock star like you,
but that's the way it is in the real world. It is still beyond my
understanding that code reviews are not mandatory for anything that is
committed in Gentoo.

Rich, if I may have a suggestion, it would be that instead of meddling
with projects that have been doing their best with what they have for
years, and which need praise rather than hindrance, you instead start
a project to get people to think positively and accept criticism. The
amount of energy that was spent in this thread and many others in pure
loss could have gone a long way.

Denis.

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

[hasufell]

Denis Dupeyron:
> 
> I honestly wonder what all the fuss is about.

It's about a dying project. I am collaborating with it since ~2 years
and it isn't getting any better (afais I'm pretty much the only regular
collaborator who is not on the team... many others stopped caring).

So, this is about:
The fact that not a single one from the team has responded here.

The fact that the lead has not contributed regularly to the project in
the last year.

The fact that the lead does not respond to people asking to join the team.

The fact that the lead didn't care about the SDL2 bump which is
basically the most important games related library.

The fact that most mails to games@ don't get any attention.

The fact that the IRC channel is almost empty.

The fact that there is no official overlay to contribute alpha/beta or
other WIP ebuilds.

The fact that there is no active work done on the eclasses and related
review requests often simply get ignored.

The fact that no one is working on improving the projects public
appearance (like the wiki).


So I am wondering what you are wondering about. Check the commit stats
in games-*/ categories. You will not see many people doing any serious
work there, except for the ones who were already mentioned in this thread.

The problems are so obvious, you really have to shut your eyes to not
see them.

[OT] Rock stars' inter-hindrance time after time, 'cause love is blind (was: Re: [gentoo-dev] The request to abolish games team policy)

[Tom Wijsman]

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

On Sat, 12 Jul 2014 16:26:10 -0600
Denis Dupeyron <calchan@gentoo.org> wrote:

> Please do not take this personally.

OK, let us try that; interesting to note though, is that this has also
been stated in the OP of this thread. People seem to do care personally
about this; repeatedly telling them not do, what effect does that have?

> I honestly wonder what all the fuss is about.

Honest questions help.

> There are a few games I've helped with over the years and I've never
> had any trouble at all having my stuff reviewed and accepted. And I'm
> a lousy ebuild writer. Every time I'd suggest a fix, bump, or new
> package, and I came with an ebuild, I would get constructive
> criticism and I could then commit it myself. Not one single time did
> I get a "no". Not once.

We've been there; however, that's not the issue at hand, it takes a
non-lousy ebuild writer to see that monopoly surrounds the core of it.

Why is that? Because it only starts to matter when it starts to matter.

> You had a fix and it was refused? Have you ever considered you may
> have been doing it wrong? I understand having to have your code
> reviewed and accepted sounds like an insult to a rock star like you,
> but that's the way it is in the real world. It is still beyond my
> understanding that code reviews are not mandatory for anything that is
> committed in Gentoo.

We all are rock stars, right?
 
> Rich, if I may have a suggestion, it would be that instead of meddling
> with projects that have been doing their best with what they have for
> years, and which need praise rather than hindrance, you instead start
> a project to get people to think positively and accept criticism. The
> amount of energy that was spent in this thread and many others in pure
> loss could have gone a long way.

Hmm, we're not sure whether we're all Rich though; if I were, I would
wonder if you have considered that hindrance works in both directions?
We are rock stars; if rock star X hinders rock star Y, Y can hinder X.

The effect of telling them to not take it personally, is that they will.

This thread is pure win, it just takes some time to see good results...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Rich Freeman]

On Sat, Jul 12, 2014 at 6:26 PM, Denis Dupeyron <calchan@gentoo.org> wrote:
> Rich, if I may have a suggestion, it would be that instead of meddling
> with projects that have been doing their best with what they have for
> years, and which need praise rather than hindrance, you instead start
> a project to get people to think positively and accept criticism. The
> amount of energy that was spent in this thread and many others in pure
> loss could have gone a long way.

The only thing that I've offered to do is to help people join the
games team, which is supposed to be an open team anyway.  That is
about the extent of the "meddling" that I've proposed.  I've yet to
hear anybody on the games team comment that more help would not be
welcome.

That said, I've also yet to hear from anybody actually interested in
joining the games team.  So, that idea may not end up going anywhere
anyway.  The premise has been that there are people interested in
working on games but they've been prevented from doing so, and working
to help improve the games team from within is better than imposing
direction from above.

If indeed nobody actually wants to join the games team, then the next
question is whether to leave things alone, or to find another
solution.  Either way I'd like to hear more from anybody who actually
wants to maintain games packages but feels they have been unable to do
so.  Simply changing policies won't make actual work happen.

Rich

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

[Vadim A. Misbakh-Soloviov]

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

=2D-nextPart1573095.DMBQqBaLzb
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

=D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 =D0=9F=D1=82, =
11 =D0=B8=D1=8E=D0=BB=D1=8F 2014 16:24:38 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C hasufell =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:

> However, basically having only a single person that actively does suc=
h
> reviews + no official overlay makes it hard for contributors.

As I said previously, you (and any developer else) are free to get a "r=
eviewer" role=20
for gamerlay (and make it official overlay).
But, AFAIR, you're opinion is hat gamerlay must die...

So, we fall into infinite circle (exaggeratedly):
=E2=80=94 There is no official overlay and no reviewers!
=E2=80=94 You can use gamerlay as a base for that and we can change our=
 workline for you.
=E2=80=94 Gamerlay is unneded!
<...>
=E2=80=94 We need reviewers and official overlay.


=2D-=20
Best regsrds,
mva


=2D-nextPart1573095.DMBQqBaLzb
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/=
REC-html40/strict.dtd">
<html><head><meta name=3D"qrichtext" content=3D"1" /><style type=3D"tex=
t/css">
p, li { white-space: pre-wrap; }
</style></head><body style=3D" font-family:'Droid Serif'; font-size:8pt=
; font-weight:600; font-style:italic;">
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">=D0=
=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 =D0=9F=D1=82, 11 =
=D0=B8=D1=8E=D0=BB=D1=8F 2014 16:24:38 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=
=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C hasufell =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0=D0=BB:</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; However, basically having only a single person that actively does suc=
h</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; reviews + no official overlay makes it hard for contributors.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">As =
I said previously, you (and any developer else) are free to get a &quot=
;reviewer&quot; role for gamerlay (and make it official overlay).</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">But=
, AFAIR, you're opinion is hat gamerlay must die...</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">So,=
 we fall into infinite circle (exaggeratedly):</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">=E2=
=80=94 There is no official overlay and no reviewers!</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">=E2=
=80=94 You can use gamerlay as a base for that and we can change our wo=
rkline for you.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">=E2=
=80=94 Gamerlay is unneded!</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&lt=
;...&gt;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">=E2=
=80=94 We need reviewers and official overlay.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">-- =
</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Bes=
t regsrds,</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
=2Dright:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">mva=
</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p></body></html>
=2D-nextPart1573095.DMBQqBaLzb--
This is a multi-part message in MIME format.

[-- Attachment #1.2: Type: text/plain, Size: 735 bytes --]

В письме от Пт, 11 июля 2014 16:24:38 пользователь hasufell написал:

> However, basically having only a single person that actively does such
> reviews + no official overlay makes it hard for contributors.

As I said previously, you (and any developer else) are free to get a "reviewer" role 
for gamerlay (and make it official overlay).
But, AFAIR, you're opinion is hat gamerlay must die...

So, we fall into infinite circle (exaggeratedly):
— There is no official overlay and no reviewers!
— You can use gamerlay as a base for that and we can change our workline for you.
— Gamerlay is unneded!
<...>
— We need reviewers and official overlay.


-- 
Best regsrds,
mva


[-- Attachment #1.3: Type: text/html, Size: 3985 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/13/2014 08:00 AM, Rich Freeman wrote:
> On Sat, Jul 12, 2014 at 6:26 PM, Denis Dupeyron
> <calchan@gentoo.org> wrote:
>> Rich, if I may have a suggestion, it would be that instead of
>> meddling with projects that have been doing their best with what
>> they have for years, and which need praise rather than hindrance,
>> you instead start a project to get people to think positively and
>> accept criticism. The amount of energy that was spent in this
>> thread and many others in pure loss could have gone a long way.
> 
> The only thing that I've offered to do is to help people join the 
> games team, which is supposed to be an open team anyway.  That is 
> about the extent of the "meddling" that I've proposed.  I've yet
> to hear anybody on the games team comment that more help would not
> be welcome.
> 
> That said, I've also yet to hear from anybody actually interested
> in joining the games team.  So, that idea may not end up going
> anywhere anyway.  The premise has been that there are people
> interested in working on games but they've been prevented from
> doing so, and working to help improve the games team from within is
> better than imposing direction from above.
> 
> If indeed nobody actually wants to join the games team, then the
> next question is whether to leave things alone, or to find another 
> solution.  Either way I'd like to hear more from anybody who
> actually wants to maintain games packages but feels they have been
> unable to do so.  Simply changing policies won't make actual work
> happen.
> 
> Rich
> 

I'm not a developer (I've completed the ebuild quiz and heroxbd is
supposed to be getting back to me), but I'm interested in helping
maintain games. I have a decent number of Humble Bundle games that I'd
love to see make it into Portage, and I could assist in testing some
games.

I recently filed a bug [1] to version bump Rochard and fix a README
filename and it's available on my own overlay [2] as well. Not to brag
or anything, but if I make developer status I'd gladly become part of
the games team.

[1]: https://bugs.gentoo.org/show_bug.cgi?id=516958
[2]; https://github.com/sporkbox/sporkbox-overlay/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTw3EvAAoJEJUrb08JgYgHh2IH/3DAbTrkUcARshsVZifqBn2d
qZVVIaOCRc8O0mTHUUNYcKOPFoC95lowglgd7zXxd5IOjvIG58TyUlTUH4tI6MKG
FeoAypecv9CC38KWaDn+WlG/uDs2WzMW8s5MnAuXXt3aSnM8D845hXuRgdDJXR0E
15AFyVDDkrnOWM2rw8Tx9VR4ZXUkokv23dCTr/oCT+aMaSGYku2yuqujYlDJnw1B
K7dgr9W1UcUlU0DnGby4mJYi/tp8fyxvaT16gE9n2EKVXeWM3DDUBJbSVKM1KWL4
QQ+uHma9cLcOYc78gNvhXqoWzG/CyWVeVmb35Bxf6v7GENlzqeaut40+5FwLi2U=
=B2xr
-----END PGP SIGNATURE-----

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

[hasufell]

Vadim A. Misbakh-Soloviov:
> В письме от Пт, 11 июля 2014 16:24:38 пользователь hasufell написал:
> 
>> However, basically having only a single person that actively does such
>> reviews + no official overlay makes it hard for contributors.
> 
> As I said previously, you (and any developer else) are free to get a "reviewer" role 
> for gamerlay (and make it official overlay).
> But, AFAIR, you're opinion is hat gamerlay must die...
> 
> So, we fall into infinite circle (exaggeratedly):
> — There is no official overlay and no reviewers!
> — You can use gamerlay as a base for that and we can change our workline for you.
> — Gamerlay is unneded!
> <...>
> — We need reviewers and official overlay.
> 
> 

When I asked you why you don't contribute to sunrise you basically
replied on a public channel:
Sep 15 18:13:50 <hasufell>	I think you are just too lazy for other
contribution channels
Sep 15 18:15:25 <mva>	not that you're fully right, but yes, something
like that. I'm too lazy to prove something somebody if it takes too much
time for me

So I think this is maybe also an ego thing (that's why you talk about
"proving something"). I have no tolerance or time for stuff like that.

People often reply aggressively to unrequested reviews or not at all, so
I stopped doing such reviews and only do it if I see that someone is
interested in improving his ebuild skills or when it matters for the tree.

That is why gamerlay is going backwards. There is no concept behind
gamerlay. The initiator doesn't care about the project anymore, there
are no policies to ensure QA or proper workflow. So yes, I don't want to
be involved with that. It's not the starting point to improve anything.
I'd have to start with removing commit rights in order to force a
review-workflow, but I can't and don't even want to do it since it's
discouraging.

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

[hasufell]

Rich Freeman:
> On Sat, Jul 12, 2014 at 6:26 PM, Denis Dupeyron <calchan@gentoo.org> wrote:
>> Rich, if I may have a suggestion, it would be that instead of meddling
>> with projects that have been doing their best with what they have for
>> years, and which need praise rather than hindrance, you instead start
>> a project to get people to think positively and accept criticism. The
>> amount of energy that was spent in this thread and many others in pure
>> loss could have gone a long way.
> 
> The only thing that I've offered to do is to help people join the
> games team, which is supposed to be an open team anyway.  That is
> about the extent of the "meddling" that I've proposed.  I've yet to
> hear anybody on the games team comment that more help would not be
> welcome.
> 
> That said, I've also yet to hear from anybody actually interested in
> joining the games team.  So, that idea may not end up going anywhere
> anyway.  The premise has been that there are people interested in
> working on games but they've been prevented from doing so, and working
> to help improve the games team from within is better than imposing
> direction from above.
> 
> If indeed nobody actually wants to join the games team, then the next
> question is whether to leave things alone, or to find another
> solution.  Either way I'd like to hear more from anybody who actually
> wants to maintain games packages but feels they have been unable to do
> so.  Simply changing policies won't make actual work happen.
> 
> Rich
> 

I appreciate your effort, but what can you do about it?

a) I'm not sure if I want to be in a team where vapier is lead. I have a
lot of respect for his technical skills/knowledge, but I don't have any
hopes for him to understand what a project lead is supposed to do
(like... answer).
b) I don't want the games team to be disbanded like QA, it will probably
make the situation worse.

I will continue to work with Mr_Bones_, but if any1 says there is no
problem with the games project, then he either doesn't know anything
about the situation or he doesn't want to know.

Again, you seem to be the only council member who cares to mediate here.
That is pretty frustrating.

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

[Sergey Popov]

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

14.07.2014 22:11, hasufell пишет:
> I will continue to work with Mr_Bones_, but if any1 says there is no
> problem with the games project, then he either doesn't know anything
> about the situation or he doesn't want to know.
> 
> Again, you seem to be the only council member who cares to mediate here.
> That is pretty frustrating.
> 

Just disband the games team and make the new one with you and Mr_Bones
as a members.

There is no point in having games team that actually does nothing.
Sometimes you just need to takeover the power and do things on your own,
like we do with arm team.

vapier was not angry when we took leadership from him(leaving him as
ordinary team member), so i think you could do this for games team as well.

And then, when people who actually do the stuff will be in team, they,
as legitimate team members could create policy for their ebuilds - all
are happy.

Of course, if we have Council blessing for all this stuff, it would be
more... legitimate, i'd say

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Proxy maintainers project lead


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

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

[Samuli Suominen]

On 15/07/14 14:18, Sergey Popov wrote:
> 14.07.2014 22:11, hasufell пишет:
>> I will continue to work with Mr_Bones_, but if any1 says there is no
>> problem with the games project, then he either doesn't know anything
>> about the situation or he doesn't want to know.
>>
>> Again, you seem to be the only council member who cares to mediate here.
>> That is pretty frustrating.
>>
> Just disband the games team and make the new one with you and Mr_Bones
> as a members.
>
> There is no point in having games team that actually does nothing.
> Sometimes you just need to takeover the power and do things on your own,
> like we do with arm team.
>
> vapier was not angry when we took leadership from him(leaving him as
> ordinary team member), so i think you could do this for games team as well.

's/disband the games team/move mr_bones_ to the lead of the current
team, as what's what he has been for couple of years de facto/'

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

[Samuli Suominen]

> 's/disband the games team/move mr_bones_ to the lead of the current
> team, as what's what he has been for couple of years de facto/'
>

*that's what

(stupid typing error)

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

[Denis Dupeyron]

On Mon, Jul 14, 2014 at 12:11 PM, hasufell <hasufell@gentoo.org> wrote:
> a) I'm not sure if I want to be in a team where vapier is lead.

The only position you don't want vapier in is behind you. He humps.

Denis.

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

[Denis Dupeyron]

On Mon, Jul 14, 2014 at 12:10 PM, hasufell <hasufell@gentoo.org> wrote:
> People often reply aggressively to unrequested reviews

People often replay aggressively when they feel aggressed. Food for thought?

Denis.

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

[Dirkjan Ochtman]

On Wed, Jul 16, 2014 at 4:35 PM, Denis Dupeyron <calchan@gentoo.org> wrote:
> The only position you don't want vapier in is behind you. He humps.

This seems rather wildly inappropriate. WTF?

Cheers,

Dirkjan

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

[Duncan]

Dirkjan Ochtman posted on Wed, 16 Jul 2014 16:53:25 +0200 as excerpted:

> On Wed, Jul 16, 2014 <someone> wrote:
>> The only position you don't want vapier in is behind you. He humps.
> 
> This seems rather wildly inappropriate. WTF?

FWIW, it's apparently an inside joke going back many years, possibly to 
before I came to gentoo over ten years ago now.  I don't know how it 
started, however, or what the exact inside joke is, but was never really 
comfortable with it myself, either.  Except that being a user on a dev 
list I feel a bit like a guest, and as a guest, unless it's criminal if 
those for whom it is home don't have a problem with it, I don't feel it's 
my place to object, more to simply uninvite myself if I'm that 
uncomfortable with it, and it turned out I wasn't /that/ uncomfortable 
with it after all.

Never-the-less, it reads like there's at least some objection now from 
someone who /can/ rightly to call this list home, and I can't disagree 
with it.  The comment does seem to have been inline with past norms, but 
I for one would consider it an improvement if I never see it here again, 
even if I don't find it objectionable enough to uninvite myself from the 
list over.

Put another way, I'm ordinarily proud to mention that I'm a gentooer and 
gentoo-dev-list regular.  I can't be proud of that comment, nor would I 
be particularly proud to claim that status in the context of that comment.
Yet as a guest here it's not a behavior norm I have much control over, 
something I /could/ point out in that context.  But I'd definitely be 
proud to be able to say that while it was an accepted norm in the past, 
that's no longer the case. =:^|

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

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

[hasufell]

Denis Dupeyron:
> On Mon, Jul 14, 2014 at 12:11 PM, hasufell <hasufell@gentoo.org> wrote:
>> a) I'm not sure if I want to be in a team where vapier is lead.
> 
> The only position you don't want vapier in is behind you. He humps.
> 

I have no idea what to respond to that, except that you seem to ignore
the actual facts I gave you.

> People often replay aggressively when they feel aggressed. Food for thought?

Yes dad. Are we derailing the thread now?

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

[Jeroen Roovers]

On Wed, 16 Jul 2014 16:53:25 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Wed, Jul 16, 2014 at 4:35 PM, Denis Dupeyron <calchan@gentoo.org>
> wrote:
> > The only position you don't want vapier in is behind you. He humps.
> 
> This seems rather wildly inappropriate. WTF?

It's an injoke. Next thing you know people start stabbing each other
like it's 2005.


      jer

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

[Ian Stakenvicius]

Sent from an iPhone, sorry for the HTML...

> On Jul 16, 2014, at 7:24 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> 
> On Wed, 16 Jul 2014 16:53:25 +0200
> Dirkjan Ochtman <djc@gentoo.org> wrote:
> 
>> On Wed, Jul 16, 2014 at 4:35 PM, Denis Dupeyron <calchan@gentoo.org>
>> wrote:
>>> The only position you don't want vapier in is behind you. He humps.
>> 
>> This seems rather wildly inappropriate. WTF?
> 
> It's an injoke. Next thing you know people start stabbing each other
> like it's 2005.
> 
> 

Long gone are the days when we would just smack each other across the face with large trout, like civilized people. <sighs nostalgically>

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

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Please stop spamming this thread now.

- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlPHiMcACgkQRtClrXBQc7WVXQEAkNAmStkzBlaFbHJVZbgZf6Et
vH/G1gzM9Znd5pI3WpwBAKYxObTCd83vJvaEyXW0f32j1E5IrZcvDs5/mmj9NtbK
=1Taa
-----END PGP SIGNATURE-----

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

[Jeroen Roovers]

On Thu, 17 Jul 2014 10:26:47 +0200
Alexander Berntsen <bernalex@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Please stop spamming this thread now.

What? Who?


     jer

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

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 230 bytes --]

> > Please stop spamming this thread now.
> 
> What? Who?
> 

Aaand now for something completely different...

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Jeroen Roovers]

On Thu, 17 Jul 2014 15:18:45 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> > > Please stop spamming this thread now.
> > 
> > What? Who?
> > 
> 
> Aaand now for something completely different...

We might as well go back to humping and stabbing if the modern
alternative is telling people to basically shut up.


     jer