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

[Ulrich Mueller]

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

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

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

Ulrich


pgpJt9yhIEkOb.pgp
Description: PGP signature

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

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

[Michael Palimaka]

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

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

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

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

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

[Michael Palimaka]

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

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

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

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

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

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

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

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

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

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

[Ulrich Mueller]

> 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


pgp9Jtsawdeqx.pgp
Description: PGP signature

[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  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] Re: The request to abolish games team policy

[Rich Freeman]

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

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

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

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

Rich

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

[Rich Freeman]

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

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

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

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

Rich

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

[Michał Górny]

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

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

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

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

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

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

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

[Rich Freeman]

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

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

Rich

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

[Ulrich Mueller]

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

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

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

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

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

Ulrich

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


pgpXJ63S4Lv_h.pgp
Description: PGP signature

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

[Ulrich Mueller]

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

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

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

Ulrich


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


pgpw_hLtRboPg.pgp
Description: PGP signature

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

[Tomáš Chvátal]

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

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

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

Tom

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

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

[Michał Górny]

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

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

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

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

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

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

[Ulrich Mueller]

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

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

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

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

Ulrich


pgpgthirFlmnq.pgp
Description: PGP signature

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

[Rich Freeman]

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

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

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

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

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

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

Rich

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

[Michał Górny]

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

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

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

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

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

[Maxim Koltsov]

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

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

-- 
Regards, Maxim.

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

[Samuli Suominen]

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

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

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

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

- Samuli

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

[Rich Freeman]

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

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

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

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

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

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

Rich

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

[hasufell]

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

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

And that is that.

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

So, it really isn't as you say.

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

[Pacho Ramos]

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

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

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

Best regards

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

[hasufell]

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

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

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

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

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

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

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

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

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

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

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

[Samuli Suominen]

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

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

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

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

- Samuli

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

[Tom Wijsman]

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

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

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

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

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

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

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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


signature.asc
Description: PGP signature

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

[Samuli Suominen]

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

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

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

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

[Rich Freeman]

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

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

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

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

Rich

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

[Rich Freeman]

On Wed, Jul 9, 2014 at 2:06 AM, Samuli Suominen  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]

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



signature.asc
Description: OpenPGP digital signature

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

[Vadim A. Misbakh-Soloviov]

В письме от Вт, 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


signature.asc
Description: This is a digitally signed message part.

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

[Rich Freeman]

On Wed, Jul 9, 2014 at 11:28 AM, Sergey Popov  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]

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


signature.asc
Description: PGP signature

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

[Tom Wijsman]

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


signature.asc
Description: PGP signature

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

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

boo

I dont see any cocin bro 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  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] Re: The request to abolish games team policy

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


--
Best regsrds,
mva



signature.asc
Description: This is a digitally signed message part.

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   I think you are just too lazy for other
contribution channels
Sep 15 18:15:25not 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] Re: The request to abolish games team policy

[Denis Dupeyron]

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

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

Denis.