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@g.o> 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