Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104269 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11782 invoked from network); 7 Feb 2019 09:32:07 -0000 Received: from unknown (HELO mail-wm1-f67.google.com) (209.85.128.67) by pb1.pair.com with SMTP; 7 Feb 2019 09:32:07 -0000 Received: by mail-wm1-f67.google.com with SMTP id y185so3498459wmd.1 for ; Wed, 06 Feb 2019 22:13:41 -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=H/4kA7q/DQxJdECBZGT2W6Na7TC641F0K5sef04Kq7c=; b=vS0nhHg3DDJYt7EZ7bseSdlYq/uLF2iPWV+Zy7zlHJNzFK2HfKcS3NC7rZhqvDN2/l hNhjhU6VIw4uNzEhig1RaURvXhMpclmY8jj2f+yidsxfVZET+L743gc+xoPDpjmytX1Y Pi9fc+FKnyw4Tv+LPYvXbVJpuZONuPcb0bkJtsBOXlk3yhRA8+0WUoRUazm57TG85hTy Vi1WVmCbyyGtVocFDTdtVjAMgACsr/ZbRLdlnqLHwocxv2n9K3+JeqIkx9Rw7gd5Mgin 43v4M+fgLu4Z6UpTmCbmxRtRimZUJsGah7TeZ0zSCWtSYXQeXzCHNm0Pzin735+OV6ak spQg== 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=H/4kA7q/DQxJdECBZGT2W6Na7TC641F0K5sef04Kq7c=; b=DwTL8l/fR2U99aWrx5piaQYPJ8IH7AjRGSBjCjW7rNIRfMBJ6JC/nZyMAK4h7mNHkl ivklcjIGDIiva8Yc3mFZUd/Gtssyx73s1PUjo9dcqsLwTetEd2BR0gvvH+qV15SffyLy 5vo5GdQifor3Dgr20AgHBlC0Me2Gu9yAzGNApIIaTpwqTITIBPuZ7RZgjwvF/ePT/1DU R2hSFGD0R5+6TsX0WahaliuNkMEH0Wt2USZJJj2bTx/ujiG4pG4FVRsoO034/zqzpUE6 4lVTyh0j9DZhEhPZ50EAYKKwz0sVJrWNYT2FLdy5UZuvNS/IXOm/pqNbkPjNvLae3ASL 4nBA== X-Gm-Message-State: AHQUAuZSf7tjqEiBxBX8dIZKxIqxSeszktusXQJQlqDWYu5RzbWGh/VB zbNWomX1gq2KDGnB6M8JsVRW3hefxynQGfPddFrN6g== X-Google-Smtp-Source: AHgI3IbGsVpThPnC3+ckAJIdg6FxMufpa4TDsj8vC7Qv7qIImBTKWR9AMgYwOF8Lvs+pWwBNLM8lGoH5/cLX+tq0pR0= X-Received: by 2002:a1c:2c44:: with SMTP id s65mr6191046wms.80.1549520020824; Wed, 06 Feb 2019 22:13:40 -0800 (PST) MIME-Version: 1.0 References: <84365f75-3335-d7fd-0aa2-e75a85b2579b@zend.com> In-Reply-To: Date: Thu, 7 Feb 2019 07:13:29 +0100 Message-ID: To: Dmitry Stogov Cc: Nikita Popov , PHP internals Content-Type: multipart/alternative; boundary="00000000000069e7da058147bef4" Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins From: krakjoe@gmail.com (Joe Watkins) --00000000000069e7da058147bef4 Content-Type: text/plain; charset="UTF-8" Morning Dmitry, I've cleaned up the proposal section to refer to the normative text section, but it remains to make clear that we are applying these rules to all RFCs (including policy amendments). Cheers Joe On Wed, 6 Feb 2019 at 22:12, Dmitry Stogov wrote: > > > On 2/6/19 8:28 PM, Joe Watkins wrote: > > Afternoon Dmitry, Nikita, > > > > I've cleaned that up to read "changes to PHP" rather than talking about > > merges, apologies for the confusion, just used the wrong words. > > > > To re-iterate what Nikita said, this is not about changing what requires > > an RFC, and not about forcing every change to require an RFC; We're all > > very aware that there is an almost constant stream of minor improvements > > committed by core maintainers that don't require RFC, and this RFC does > > not seek to stand in your way. > > The "Normative text" section looks clear now. > I would remove all the rest of the "Proposal" section, assuming that > it's reflected in the "Normative text", anyway. > > Additional note (unrelated to this RFC, but related to RFC process). > It would be great to define some formal procedure of approval of RFC > implementation patches. > - When a patch is required and good enough, to turn RFC into voting? > - When a patch of accepted RFC may (or may not) be merged? > > Currently, this procedure is completely informal. > > Thanks. Dmitry. > > > > > > Cheers > > Joe > > > > On Wed, 6 Feb 2019 at 17:31, Nikita Popov > > wrote: > > > > On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov > > wrote: > > > > > > > > On 2/6/19 11:50 AM, Nikita Popov wrote: > > > 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. > > > > First, take the words from this RFC: "Anything merged into > > php-src is by > > definition a core part of PHP, regardless of the folder it goes > > into, or > > whether it has direct implications for our users. This is not a > > debatable fact: If it is distributed with PHP, it is core > software". > > > > Does this mean that every merge into php-src requires vote? > > If not, why this sentence is here? > > > > Second, many significant internal improvements don't affect PHP > > behavior > > at all. Usually, they affect just few core developers and few > > third-party extensions maintainers. Should this really require > > super > > majority of all the voters? Or we can avoid voting, instead? > > > > We currently have voting rules, that more or less work. > > > > In case, anyone like to change them, it would be better to > > present new > > rules as a "DIFF" on top of existing ones (in the most possible > > compact, > > clear and formal way). Then we may vote on the whole "DIFF", or > > each > > change separately. > > > > I wouldn't vote for changes of rules without clear context. > > I hate politics, and wouldn't like to participate in this > > discussion :( > > > > > > Thanks for the feedback. I have added a new section to the RFC with > > the precise change that will be applied to the voting RFC: > > https://wiki.php.net/rfc/abolish-narrow-margins#normative_text > > > > This is the whole change and nothing else will change. It is > > exclusively about requiring 2/3 majority for the main RFC vote. It > > does not change anything about the kind of changes that need an RFC, > > and certainly doesn't require RFCs or votes for every merge... > > Probably the rest of the RFC text should also be cleaned up a bit, > > as I agree that the focus on "merges" is confusing (not all RFCs > > even have an implementation at the time of vote.) > > > > Nikita > > > --00000000000069e7da058147bef4--