From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C12F31396D9 for ; Mon, 13 Nov 2017 17:34:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC506E1122; Mon, 13 Nov 2017 17:34:13 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8AC96E1122 for ; Mon, 13 Nov 2017 17:34:13 +0000 (UTC) Received: from oystercatcher.gentoo.org (oystercatcher.gentoo.org [148.251.78.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id C942B33BF43 for ; Mon, 13 Nov 2017 17:34:11 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id 3782E9ACF for ; Mon, 13 Nov 2017 17:34:10 +0000 (UTC) From: "Ulrich Müller" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Ulrich Müller" Message-ID: <1510594276.5a83443adb451df4036f161cd8f6a4061d2f9e51.ulm@gentoo> Subject: [gentoo-commits] data/glep:master commit in: / X-VCS-Repository: data/glep X-VCS-Files: glep-0039.rst X-VCS-Directories: / X-VCS-Committer: ulm X-VCS-Committer-Name: Ulrich Müller X-VCS-Revision: 5a83443adb451df4036f161cd8f6a4061d2f9e51 X-VCS-Branch: master Date: Mon, 13 Nov 2017 17:34:10 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Archives-Salt: b1767dc2-2766-4a17-b07b-38dc0bb6afaa X-Archives-Hash: f4ca61dc191c49356df8c9b78a800de0 commit: 5a83443adb451df4036f161cd8f6a4061d2f9e51 Author: Ulrich Müller gentoo org> AuthorDate: Mon Nov 13 17:31:16 2017 +0000 Commit: Ulrich Müller gentoo org> CommitDate: Mon Nov 13 17:31:16 2017 +0000 URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=5a83443a glep-0039: Fix indentation. The Rationale section was not properly rendered as an ordered list because of the missing indentation. glep-0039.rst | 50 +++++++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/glep-0039.rst b/glep-0039.rst index 8f61643..396fb42 100644 --- a/glep-0039.rst +++ b/glep-0039.rst @@ -166,42 +166,42 @@ Rationale So, does this proposal solve any of the previously-mentioned problems? 1. There is no longer any requirement that the project structure be -complete. Some devs work on very specific parts of the tree, while -some work on practically everything; neither should be shoehorned into -an ad-hoc project structure. Moreover, it should be easy to create new -projects where needed (and remove them when they are not), which this -proposal should enable. + complete. Some devs work on very specific parts of the tree, while + some work on practically everything; neither should be shoehorned into + an ad-hoc project structure. Moreover, it should be easy to create new + projects where needed (and remove them when they are not), which this + proposal should enable. 2. By having the members choose their project leads periodically, the -project leads are necessarily at least somewhat responsible (and hopefully -responsive) to the project members. This proposal has removed the list of -responsibilities that project leads were supposed to satisfy, since hardly -anybody has ever looked at the original list since it was written. Instead -the practical responsibility of a lead is "whatever the members require", and -if that isn't satisfied, the members can get a new lead (if they can find -somebody to take the job!). + project leads are necessarily at least somewhat responsible (and + hopefully responsive) to the project members. This proposal has + removed the list of responsibilities that project leads were supposed + to satisfy, since hardly anybody has ever looked at the original list + since it was written. Instead the practical responsibility of a lead + is "whatever the members require", and if that isn't satisfied, the + members can get a new lead (if they can find somebody to take the job!). 3. If the council does a lousy job handling global issues (or has no -global vision), vote out the bums. + global vision), vote out the bums. 4. Since everybody gets to vote for the council members, at least in -principle the council members represent all developers, not just a -particular subset. + principle the council members represent all developers, not just a + particular subset. 5. An appeal process should make disciplinary enforcement both less -capricious and more palatable. + capricious and more palatable. -6. This proposal doesn't help find inactive devs or projects. It -really should not be that much of a problem. We already have a script for -identifying devs who haven't made a CVS commit within a certain period of -time. As for moribund projects, if the project page isn't maintained, it's -dead, and we should remove it. That, too, could be automated. A much bigger -problem is understaffed herds, but more organization is not necessarily a -solution. +6. This proposal doesn't help find inactive devs or projects. It really + should not be that much of a problem. We already have a script + for identifying devs who haven't made a CVS commit within a certain + period of time. As for moribund projects, if the project page isn't + maintained, it's dead, and we should remove it. That, too, could be + automated. A much bigger problem is understaffed herds, but more + organization is not necessarily a solution. 7. The metabug project is a great idea. Let's do that! Adding a useful -project shouldn't require "metastructure reform", although with the -current system it does. With this proposal it wouldn't. + project shouldn't require "metastructure reform", although with the + current system it does. With this proposal it wouldn't. 8. This proposal has nothing to say about GLEPs.