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 E5BF8138334 for ; Thu, 28 Jun 2018 17:24:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 90EF5E0871; Thu, 28 Jun 2018 17:24:40 +0000 (UTC) Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41]) (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 4D7D8E085E for ; Thu, 28 Jun 2018 17:24:40 +0000 (UTC) Received: by mail-pg0-f41.google.com with SMTP id a14-v6so2758444pgw.10 for ; Thu, 28 Jun 2018 10:24:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=JfTtu2iR/CZuznqv2nqjFTGjmouLHPDO7U50oQFJKZE=; b=UOWeu3GlCopnI7VOWarnJby1d16Be9yr4dYkpcQ1lNIsd6En+eSHK3ETVI8LmF52yg myj3mNCjzJ9n7m7cEurr6zeVxJiSCUY9PQCxRwd71UyAJEIg8wjJyhqZUcLxI8UE9soT kfIgpPqooK2uA4wO1a7T4MMkjtbOBMTiKDUm/LOPRsheGVdKQIqHuB6FVv9xNwU+Tppc SVMRGKGxe+4gHjQ8YmRYmfzo+iy3Jg1zIqIGjD8zjfZA4GvRfFo6Hv3L/ve718Zj6AnB bgTCZZLhGPRCKpSG1CJgJGkyqXR99vWQIKPVl7Qe+dEc9bmh9eMvrarzwALFvXYumFnv jfVg== X-Gm-Message-State: APt69E0GLzoEK8b9BSFZjJUS2l94MCuz2fmEc7YKMeFo3BOrUFkMZNcx S2zQ+zpexPhjXYTUHVSlaQ8J773OpLTRZvX+2SdBHw== X-Google-Smtp-Source: AAOMgpcaLD9qcjZPcuIdki48eUqJB6NIgEnNKfRCk0JYH1z+WyObjwrcMZHMqZtu1CzP2TfF7EPz9kKmE05MCxATZFA= X-Received: by 2002:a62:3d0c:: with SMTP id k12-v6mr7846319pfa.179.1530206678707; Thu, 28 Jun 2018 10:24:38 -0700 (PDT) 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 References: <1530202455.901.3.camel@gentoo.org> In-Reply-To: <1530202455.901.3.camel@gentoo.org> From: Rich Freeman Date: Thu, 28 Jun 2018 13:24:27 -0400 Message-ID: Subject: Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution To: gentoo-project Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 0f12e836-4d55-41c5-9153-89c7a6291f95 X-Archives-Hash: d9c662f4d07f1a1825d5fe8fe091eb2d On Thu, Jun 28, 2018 at 12:14 PM Micha=C5=82 G=C3=B3rny = wrote: > > a. the Council decision in question is final (i.e. a general > resolution can not be used to bypass the Council), One question that this brings up in my mind is the duration of these decisions, because Council decisions are never really final. The Council can override its own decisions, or the decision of a prior Council. Presumably you wouldn't want the current Council to be able to override a GR, but how about a subsequent one? A lot of decisions are made on the basis of some context that could change. To use your example, suppose there is a GR to make OpenRC the default service manager. Great. What happens in 10 years when it makes sense to make some new service manager the default? Normally such a decision wouldn't even require a Council vote, but if the previous GR has no expiration, then does that mean that another GR is required to make a decision that may not be as controversial in the future? To use a different example, consider GLEP 39. Many consider GLEP 39 to be special and one that the Council cannot modify, but on the flip side there is currently no real defined process for changing it. (Perhaps GRs will become such a mechanism.) The result is that sometimes changes that might make sense don't really get considered because nobody feels empowered to make it happen. In any case, my point is mainly that the GR GLEP ought to indicate one way or another how a GR can be modified. Presumably a GR can always be used to modify a previous GR. However, do we want to relax things further, such as by allowing GRs to be overriden by Council if there has been a Council election in the interim? My last comment is more philosophical. I do support the concept behind this, but I do want to note that it is a lot easier to vote for something to happen than to actually make it happen. If devs consistently vote for Council members who support position A, but then vote via GR to impose position NOT A, it creates a bit of organizational schizophrenia as there really is no executive process to appeal council decisions and thus you end up tasking people to execute a policy they don't actually agree with, as volunteers. The likely result will be half-hearted at best, even if no outright defiance takes place. So, this is a mechanism that will need to be used carefully, but I think having it available as a recourse is better than not having it available. --=20 Rich