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