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 19BAF1391DB for ; Fri, 1 Aug 2014 00:29:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B5749E08DA; Fri, 1 Aug 2014 00:29:28 +0000 (UTC) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1D72BE08C4 for ; Fri, 1 Aug 2014 00:29:27 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id la4so5602602vcb.33 for ; Thu, 31 Jul 2014 17:29:27 -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=/kr4F8dJWliivIicAIQVsgcbhCPqfyM6bljtOnPNEPI=; b=cUBxcaD/16eE59W4REPr1ikJfuhS08i1b1epALvMTGrNZScR4PU0T+JuDb3WyJnp3c y0GvLSF7FxdsXscazMb/BYwPyXrGnO0t5Fg0GaSqP7q24Yz3740C6wgTqi6ge/9CdYRI Z4+MWl+hjUV0qDGUOhuF6q9PRKUdPiA2ufZeVQLJclOK2IvRYPIEvzeWLqgkW/DAWtqx U3vLwHy4uiRCMqFuIDjdKC5coBBV12m0a5qINx5ODP0+YnCzC1K35UYR76/dQdRGFk9M y15IQgevPvVBry0QkIvGCSsgfW/Vh1wzla7MfSlOxeUFxjKWPrsFdF+2HbXjkPjYAwoU Pvvg== 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 ty7mr2326622vcb.14.1406852966991; Thu, 31 Jul 2014 17:29:26 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Thu, 31 Jul 2014 17:29:26 -0700 (PDT) In-Reply-To: <53DA2D60.3010600@gentoo.org> References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> <1901231.LPrcrkj2db@kailua> <1922162.cLrbk3D9LS@kailua> <53DA2D60.3010600@gentoo.org> Date: Thu, 31 Jul 2014 20:29:26 -0400 X-Google-Sender-Auth: 7DfKOpPSft0zivaBG5cUPVFTgrE Message-ID: Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12 From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 03914219-d0d2-449b-86bb-325eb0ea61c2 X-Archives-Hash: eee6701b910684e4898686b8090a021c On Thu, Jul 31, 2014 at 7:49 AM, hasufell wrote: > Rich Freeman: >> >> 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). > > You want to force-push members into a team while "preserving" the old > structure? That calls for trouble. I'm just saying it is one possible option, so don't get carried away with the "you." It was actually my first preference though, and it looks like others would prefer this as well. It isn't about force-pushing. Gentoo projects are generally supposed to be open-access (with the exception of QA, Comrel, and Infra), so if people want to join they should be able to do so unless there is a good reason to exclude them. Likewise, teams are supposed to elect leads annually. So, this is just about removing bureaucratic roadblocks for people who want to join the games project. The majority can then set policy as they see fit, which is basically the process in GLEP 39. Project leads not responding to requests to join is an abnormality. However, I don't exactly see people lining up to join the games project, so this is a bit of a moot point. > >> 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). > > That's contradictory, IMO. You are practically telling the games team > "your policies suck, so we just changed them". That doesn't really mean > they preserve their scope. To clarify - by scope I meant preserving their claim on any game in the tree. So, with this option all games have to still follow games project policy, but those policies would be directly tweaked by the Council. I don't like this option either - I was just trying to spark discussion and include potential options. >> 3. Restrict the games project scope, such as giving it authority if >> the package maintainer elects to put it in the games herd. > > This calls for trouble as well and will cause massive inconsistency. It certainly has that potential. However, part of GLEP 39 is that projects are allowed to compete, and inconsistent treatment of /usr/games or the games group isn't half as confusing as multiple udev implementations, sysvinit, package managers, and so on. I think it is an option worth considering. I wouldn't call it my favorite option though. > > 5. Have undertakers check for slacking project leads and accept related > complaints. If a project has a slacking lead, then the project should be > given a (long) deadline to fix it. If they don't fix it, then they > should be disbanded. A project cannot function properly without an > active lead (unless the project structure defines that there is no lead > anyway). > So, this is basically a variation on #1, but I'd rather see people joining a project and breathing life into it rather than projects simply being disbanded entirely. That said, if NOBODY was on the games project and its policies were in the way then disbanding it would be an option. That really isn't the case - there are active devs on the games project - they're just not following GLEP 39 by holding elections and generally being accepting of members. I realize this isn't really adding anything much - I really just wanted to clarify my meaning with the various options and generally spark feedback. Rich