Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104231 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69125 invoked from network); 6 Feb 2019 12:09:32 -0000 Received: from unknown (HELO mail-it1-f196.google.com) (209.85.166.196) by pb1.pair.com with SMTP; 6 Feb 2019 12:09:32 -0000 Received: by mail-it1-f196.google.com with SMTP id w18so4490763ite.1 for ; Wed, 06 Feb 2019 00:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v1fxUD31I9Wufaw130lGPme8VBTkiUAFXm+LXFCKPtU=; b=NZGfH0RLTxGqyW9vFC1OYSqHFXy67MD0nrqVe53X6TQ0yl6s81uWkob1To5GkGPB4+ PqqB4p6WWht/4B+gR0QrCtj9sxkuA9RI8+Te0elmxCwOK7rETsw2wbJho+uPjIcQKmQ1 JrOSay+TfBxfQk1QTkHg1VVC+ix8ent/icjtCViLEn7Gz32W3Bvh5LnNFKSUr0qAC6g1 rCw0aN/xSbRW6sqGsRhbPO13/2cDMUcCyL4qaWhKB1RHKC7wAQikC3pCEeYaKPdpmOXk EK42gEwbDtwCHfjbvYhBFwFK145sKr1Qb/+4bmFPahOS/7hgxQkDYC62Fu86uPReUJje ++ag== 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:cc; bh=v1fxUD31I9Wufaw130lGPme8VBTkiUAFXm+LXFCKPtU=; b=iqGBHnUKpwcYlsLggO6uoM5SCSXy3bZoqWeyjzW9lm0MdvmhpZ3m54ww0sI8xJHSGa eonQ0Pv+GhYhBinqtSUx/Hy23rnrYAhNx3TpDifuzSBeedf/Ojz6y1UJUTTRYru+bnUs YDYWRHmkjXEoTrfNCJjJQ0UQvrQEb/Q/UENACIp60abfoGkfb2l5h+ZeQqZYBaHUfaMV 5DPOgjYGWUy54sSY2KxvTeJRG9tWaZIyN1XrNa7p4DC+Pzg74RHS2i4NLrb2zrT63V0f w0HL0vJPLJ/02QilByovkW6bDTxvzoc6d/KEZ0nWZuHJj53wH5T8hxSWVOcQc7h9+ZuH DbGg== X-Gm-Message-State: AHQUAuY0yPywuU5TZZh6x4hABJ4gXbrPmDj7wopR+FDyBjDyzbXtMLRO dU6g/ya5Y4LLop1nHa4HgPLRf4J4WIfTegDByaE= X-Google-Smtp-Source: AHgI3IZWlbZ0ZrOsVRuc+MHfsBH4UTDLKoh9ecDBGwBFpkpb2EthlMcyFhL6+uFAuSloZarLlX5dBxWH1hq+9ZNRkrU= X-Received: by 2002:a5e:c906:: with SMTP id z6mr4783846iol.47.1549443053072; Wed, 06 Feb 2019 00:50:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 6 Feb 2019 09:50:34 +0100 Message-ID: To: Joe Watkins Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000c7360a058135d2f4" Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins From: nikita.ppv@gmail.com (Nikita Popov) --000000000000c7360a058135d2f4 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins wrote: > Afternoon internals, > > Some time ago I brought up for discussion: > https://wiki.php.net/rfc/abolish-narrow-margins > > I intend to bring this up for vote in the next few days. > > Cheers > Joe > After one day of heated discussion this thread has died down again. I'd like to make sure that there are no further concerns here before this goes to vote. Most of the discussion here has been around the question of whether or not this should be part of Zeev's RFC (and it doesn't look like we're going to agree on that one), but there has been little further discussion of the proposal itself. I guess that means it's fairly uncontroversial. As far as I can see the only difference between this proposal and Zeev's (as far as voting margins are concerned), is that this RFC requires a 2/3 majority, while Zeev's proposal excludes "PHP Packaging Decisions" and only requires a simple majority for them. There has been some brief discussion about this, with the following mail from Stas: > 1. Do we really need different classification of changes? I think having > one single vote procedure would have larger benefit, and RFC that fails > 2/3 requirement would be suspect anyway. RFCs can have parts - "whether > we do it" and "how exactly we do it" - the former would be 2/3 > requirement, the latter can be simple plurality even - e.g. if we decide > to have an extension for libfoobar, that should have 2/3 vote, but then > decision between whether to name it foobar or barfoo can be decided by > majority or plurality. And Zeev's response: > I think we do. There are decisions where a 2/3 majority requirement makes > no sense, as the vote itself is about a choice between two options that are > on the table, as opposed to deciding whether to do something or not. > There aren't many such cases, but when they do occur - they tend to be > important. > > The most obvious case I have in mind is that of the choice between PHP 6 > and 7. It doesn't expose us to any future commitments, doesn't change the > language - it's arguably almost a marketing decision. Similarly, if we > decide to change our release schedule, I don't see why that should require > a 2/3 majority. The 'bias for the status quo', which is the main reason we > have the super majority requirement to begin with, doesn't really play a > role here - as it bears no long term commitment. I'll add my own response here. I agree with Stas that it is preferable to have a single voting procedure and don't think that "packaging decisions" should be special cased. This is not just to in the interest of having simple rules, but also because I disagree with the premise that packaging decisions are somehow less important than changes to PHP or do not have future commitments. For example, extending support for a release by multiple years (a question that will probably come up for PHP 7.4), is a quite serious commitment of resources that should not be decided on a narrow margin. More importantly, while our past RFCs in the area of "packaging" have not been particularly major, that's isn't a property inherent to the category. For example, a proposal to introduce regular LTS releases, or to make other major changes to our release scheduling, should certainly be subject to a 2/3 majority. In each category (whether it's changes to PHP or the release process) there will always be more and less significant RFCs, and it's hard to draw a good line between them (we failed spectacularly trying to due that with "language changes"). I think it is better to err on the side of being conservative and require a 2/3 majority for everything, especially as it also obviates any arguments as to what requires or doesn't require a certain majority. Nikita --000000000000c7360a058135d2f4--