From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9AD351393DD for ; Wed, 9 Jul 2014 08:16:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 78F9BE0826; Wed, 9 Jul 2014 08:16:32 +0000 (UTC) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 87609E0807 for ; Wed, 9 Jul 2014 08:16:31 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id i13so6917082veh.1 for ; Wed, 09 Jul 2014 01:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Ko5Ze0ggp0LKbWtEFkSLzQ6XtmZgWdnE5kFW/v0hWYc=; b=CRK0vP5Iq1Uu7PiA1F9HP6eJT1JKEn+dmUnIt9Po2anom2gDtiHUJN2PQDQz9vt2B0 BEn+LwmPsS9wnKYKN+aj3H6LrR3aKDUnGVqRwWCjXDBLotGOIjB4k/22Pveb08sXCUSr WUhnZjFAARXBBz9AzKjBaK84Di3usADOMCeI4129G45gERj/24TL6eeIRdqwZ0F8O3Nr dl7QGbae9jwBDsCVhMyCR+isjMMQ44o7WqCFjr0aI54jBRCSSccybH1KNRacJuURFgBG n6seKOQk51N2jcSZYozIctREMz8qsmEelJe9LC7vXpCXEh9AKriqrxy74ZCqG5mpLhIB okcA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.121.112 with SMTP id lj16mr32014857vdb.29.1404893790764; Wed, 09 Jul 2014 01:16:30 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.72.19 with HTTP; Wed, 9 Jul 2014 01:16:30 -0700 (PDT) In-Reply-To: <53BCDBD3.7080100@gentoo.org> References: <20140707234502.3009929a@pomiot.lan> <20140708133859.3bc01349@pomiot.lan> <53BC0CCA.4000702@gentoo.org> <53BCBD4A.3020909@gentoo.org> <20140709062410.24b4220a@gentoo.org> <53BCDBD3.7080100@gentoo.org> Date: Wed, 9 Jul 2014 04:16:30 -0400 X-Google-Sender-Auth: 8pse_MguvlkmQwQKwFDG2HoN7BQ Message-ID: Subject: Re: [gentoo-dev] Re: The request to abolish games team policy From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 96bc10ae-cbdf-4455-bde8-f39221044917 X-Archives-Hash: 31af7de65302524d3ae7b1b95210ddf6 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