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 6061413877A for ; Thu, 31 Jul 2014 10:53:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5C11EE0960; Thu, 31 Jul 2014 10:53:52 +0000 (UTC) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C0760E095F for ; Thu, 31 Jul 2014 10:53:51 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id le20so3813678vcb.14 for ; Thu, 31 Jul 2014 03:53:50 -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:cc:content-type; bh=jalPjYigJDO92uH3+50ZxZjIjFXgLordUlmThtbColc=; b=FzIick2M+M0oSWrj4z7UJFY9MzLIjOA+dmzH4B8KKS9BNiHNE3zp+H1qYOhHd8M8cO sYpHwDt6xOeK1reTrS8RDDkomB38TRTkO0WqbYVytMAo5eBVe8muerZtLiAJYHr1azdd KHOBF9uP2y/yzKuBz2tjlmlrxf2s6BOnZUiWk3ERBq3z8A0I/EfecEdz1WMQ8/EmBEBo NLI7paGH6xfXFaZllQHCUWLuCiE2C25BgiV9x/fv6IQ/5da1ymwIoFY/FZPilXCmvqaG wiCzVqZnNi/j/xb+694qS2KmRKdgv6IVo/QyyPpR9n6VXS6vgB5O066ugZD80nK74MEv h3Ww== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.221.42.135 with SMTP id ty7mr11626499vcb.14.1406804030833; Thu, 31 Jul 2014 03:53:50 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Thu, 31 Jul 2014 03:53:50 -0700 (PDT) In-Reply-To: <1922162.cLrbk3D9LS@kailua> References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> <1901231.LPrcrkj2db@kailua> <1922162.cLrbk3D9LS@kailua> Date: Thu, 31 Jul 2014 06:53:50 -0400 X-Google-Sender-Auth: pGGDpDrQAtzBQcDeiXluDh-pxqo Message-ID: Subject: Re: Re: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12 From: Rich Freeman To: gentoo-project@lists.gentoo.org Cc: Michael Sterrett , games@gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: f3001ed7-0572-4411-a3fd-8fddd6de92c8 X-Archives-Hash: 160c8956b6e066d9364c23186aecedce On Wed, Jul 30, 2014 at 2:15 PM, Andreas K. Huettel wrote: >> I didn't bother replying before because I think my assumption was that >> the council was clever enough to recognize silly when they saw it. >> There never was a compelling argument for dispelling policy set by >> groups in the general case and I'm not sure why the games group would >> be considered to have lesser status in that regard. > > That actually doesn't address any of the issues brought up. > > The main question is, why should the games team have more status than other > projects? ++ Generally I am in favor of giving projects that adhere to GLEP39 more of a say in things than individual maintainers, but setting aside QA/Comrel/Infra there aren't really any projects out there which claim the same kind of scope as games. Amd64 might have a say over your KEYWORDS, or systemd might want to install a text file you don't have to look at, but none of them are going to basically rewrite your ebuild, rename it, or tell you to get it out of the tree. The Gnome/KDE projects don't care if you install an application that uses libkde/etc, though you'd do well to coordinate if you don't want random breakage on the next big change. If this were just an issue about games not accepting new members I think that would be pretty trivial to fix, but I haven't gotten any replies to my solicitation. So, this is more than whether the lead responds to member requests. Some options open to the council are: 1. Let the games project keep its policy, and anybody who wants to change this has to join the project and call for elections (the council can shoe-horn members onto the project if necessary). 2. Directly tweak games policy but preserve the project and its scope. So, games would still have to adhere to games project policy, but the Council might change specific policies (use of eclass, group, etc). 3. Restrict the games project scope, such as giving it authority if the package maintainer elects to put it in the games herd. 4. Do nothing. I think #1 is the least intrusive (besides #4), but since nobody responded to my call for new members I don't know that it will accomplish anything. I don't really care for #2 - it seems the most meddlesome and I'm not sure what would be left for the project to actually do if we basically ripped out all their policies and told them they can't change them. Do we really have a sense for how much demand there is for change? #4 (or something equivalent like nicely asking games to deal with this) might make sense if we think this is really just 2-3 devs with an opinion, and that there isn't a larger demand out there. However, right now #3 is where I'm somewhat leaning personally. I think it would be helpful if more members of the community with a strong opinion speak up. Apologies to the games project if it seems like we're demanding a performance, but in the end the Council is as much bottom-up as top-down and if all we hear is people demanding a change, it is a bit hard to just ignore it, and really, listening to the community is everybody's job anyway. Rich