Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102718
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ncsu.edu from 209.85.218.42 cause and error)
MIME-Version: 1.0
References: <CAESVnVoRW7kovTAPPqb1PBbrabtbwR==ZW8QSGoeFWBzS68-sQ@mail.gmail.com>
 <CADMz3wckg0t1WgF56+CXZw2CNS4MB3LDwEL6XQY7Tyu18iDUcw@mail.gmail.com> <CAESVnVoiAeYfRa+Wsreh4+_QVZz_4-985VYpZQEUMn7WsjyUBQ@mail.gmail.com>
In-Reply-To: <CAESVnVoiAeYfRa+Wsreh4+_QVZz_4-985VYpZQEUMn7WsjyUBQ@mail.gmail.com>
Date: Tue, 10 Jul 2018 15:26:19 +0000
Message-ID: <CADMz3weDX-hhhM8mnbFLbCL31EJAo9hUprWpp=PSuMwa=_SazQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] On not rushing things at the last minute
From: mdwheele@ncsu.edu (Dustin Wheeler)

On Tue, Jul 10, 2018 at 1:43 PM Sara Golemon <pollita@php.net> wrote:
>
> On Tue, Jul 10, 2018 at 9:26 AM, Dustin Wheeler <mdwheele@ncsu.edu> wrote:
> > That said, if feature freeze for a release is announced well in
> > advance, published,
> >
> Depends on what you consider a proper announcement[1], but it is
> published[2] and the date can reliably be expected to occur around
> mid-July until and unless we change the GA date (FF is 18 weeks and 2
> days prior to GA, GA in turn is approximately 4 weeks before
> Christmas).  I'll admit that the publishing of the 7.3 timeline came
> very late this year and that's on myself and Remi.  The RM selection
> process should have started two months earlier than it did.
>

Yeah, I worded that pretty terribly. I should have put a parenthetical
after that if statement. Agree 100% on adequate annoucement.

> > and there was an agreed "best intentions" policy
> > to not submit RFCs that encroach on that date,
> >
> I had hoped there already was an agreement on this.  Seeing the SIX
> currently in voting makes me doubt that understanding is shared (okay,
> in fairness, Class Friendship isn't targeting 7.3).
>

Class Friendship is currently targeting the trash! :P

> > That, or subconsciously, the talk of a new version of
> > PHP sparked folks to get off their ass and put forth their ideas! :P
> >
> That's very likely a contributing factor, especially with talk of 7.4
> being deprecations focused (something I'm finding myself agreeing with
> less and less over time).  This isn't new to this year though, even if
> it's been less pronounced till now.
>

I'm relatively new to all of this. I think it's a bit strange to
earmark a minor release as deprecation-only, but I also wasn't around
for the last major upgrade to see discussion (was 5.6 the focus of
many deprecations?)

It can be frustrating, but I really like to see humans conversing and
finding flexible solutions for the greater good (which is already
happening here). Perhaps there is a reasonable way to document /
communicate the shared understanding that "sending new RFCs to a
release that's so close to feature freeze that it's questionable
whether voting will end in time" is bad form. Having a parenthetical
that covers "exceptional work" could also address situations like the
property types RFC, which ... not to minimize ANY other work on-going
... is in my opinion, worthy of such an exception.

Where would be a good place to document that? https://wiki.php.net/rfc/howto?

-- 
Dustin Wheeler | Software Developer
NC State University
mdwheele@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."