I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of quiet followed by
weeks of chaos every year around this time. This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.
What are the causes?
Is it seasonal? Some people have more time during the summer because
of school/family schedules? Maybe the solution is to shift the
release window a few months in one direction or the other.
Is it failing to get our shit together? Maybe we should discourage
late RFCs by requiring a higher voting threshold? e.g. You can open
voting as ridiculously late as a week before feature freeze (honestly,
who would do that?) if you want, but you'll need an extra 10% to pass
on top of whichever threshold already applies.
We don't need to solve this now, this week, because there are plenty
of rushed, last-minute proposals on the table already. But I'd like
folks to start thinking about this and ways we can mitigate this
problem come future releases.
-Sara
We don't need to solve this now, this week, because there are plenty
of rushed, last-minute proposals on the table already. But I'd like
folks to start thinking about this and ways we can mitigate this
problem come future releases.-Sara
--
I agree with Sara. This is definitely a worthwhile discussion and the
issue probably puts additional stress on RMs that may be easily
avoided.
Personally (for Class Friendship), I opted to target either 7.4 or 8.0
(whichever was decided to be next-in-line; but specifically NOT 7.3
due to more important discussions happening at the moment. So I think
there's some "personal judgment calls" to make for folks submitting
RFCs.
At the same time, I would hate to see a TON of additional process /
voting constraints come as a response to this issue.
That said, if feature freeze for a release is announced well in
advance, published, and there was an agreed "best intentions" policy
to not submit RFCs that encroach on that date, then I think all would
be well. I don't think there's any intent to slide features in under
the finish line. It just seems like a lot of ideas finished baking at
a weird time. That, or subconsciously, the talk of a new version of
PHP sparked folks to get off their ass and put forth their ideas! :P
Just my 2c, FWIW
--
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."
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.
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).
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.
-Sara
1 - https://externals.io/message/102031#102031
2 - https://wiki.php.net/todo/php73
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! :PThat'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."
Den tir. 10. jul. 2018 kl. 17.26 skrev Dustin Wheeler mdwheele@ncsu.edu:
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?)
Afair then it was proposed to have PHP 5.7 as a deprecation/migration
friendly release but we ended just rolling with PHP7 and the migration
was merely flawless. Personally I don't like the idea of such type of
releases either, I think they make sense on paper but reality is also
that we have a branch to support for years to come as to our current
release policy.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
snip
Personally (for Class Friendship), I opted to target either 7.4 or 8.0
(whichever was decided to be next-in-line)
Seems to me this is one of the issues - that this is something that isn't
just set in stone. If there was an overall roadmap of major and minor
versions, along with set dates and deadlines that could not be moved, this
wouldn't be an issue.
At the same time, I would hate to see a TON of additional process /
voting constraints come as a response to this issue.That said, if feature freeze for a release is announced well in
advance, published, and there was an agreed "best intentions" policy
to not submit RFCs that encroach on that date, then I think all would
be well. I don't think there's any intent to slide features in under
the finish line. It just seems like a lot of ideas finished baking at
a weird time. That, or subconsciously, the talk of a new version of
PHP sparked folks to get off their ass and put forth their ideas! :P
I think a hard deadline would be a better solution. Past that date, it
simply doesn't matter what the RFC is about, it'll make the next version at
the earliest, not the current one. Movable feature freeze and release dates
do not benefit the language or its users, nor most of the core developers,
I'd say.
Just my take on it.
--
CV: https://stackoverflow.com/cv/peterlind
LinkedIn: plind
Twitter: kafe15
I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of quiet followed by
weeks of chaos every year around this time. This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.-Sara
I'd like to see confirmed security vulnerabilities and bug squashing be
made a priority over new features.
Bug #73535 is still open, unaddressed, and unmitigated...
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
Hi,
I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of quiet followed by
weeks of chaos every year around this time. This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.What are the causes?
Aside from life keeping you busy until you realize it's that time of
the year again, I believe it's just the short development cycle and is
no coincidence that this has been happenning more often since getting
into a yearly schedule.
In my observation, adoption rates are slower than the release cycle
and so it's kind of like ... I barely got to enjoy the shiny new thing
and the next feature freeze is already happening. And then also, we're
always eager to get our idea in before feature freeze, but that's hard
to achieve unless we come up with it in January or earlier, but since
everybody's naturally got their eyes set on version.next, few people
think about X.Z before X.Y is released.
I don't know if this can be fixed though. It's just hard to keep up
with schedules on side projects and let's face it - PHP is nobody's
primary job, so any work spent on it is by definition a side project.
Cheers,
Andrey.
Hi!
I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of quiet followed by
weeks of chaos every year around this time. This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.
Yeah, I think it is natural (when deadline is closing in, people start
to rush in), but not good. And I would feel for big features, like typed
properties or friend classes (without touching its merits) I think they
should target 7.4.
In the future, I think the expectation should be that if you have a
large improvement it should not be expected to land in the version that
is already in the release cycle, even before feature freeze (especially
if "before" is measured in mere days). Large features take time to
figure out and stabilize, and that should be the expectation. So you can
write the RFC and open the vote whenever you want and whenever the life
allows you the time to do it, but the expectation of where it lands
should not be "immediately", especially for big ones.
What is "big" is subjective of course, but deep language level changes
(typing, strictness, changing how major parts of language work, major
language feature like, I dunno, named arguments?) are big, and most
deprecations or individual function additions aren't.
--
Stas Malyshev
smalyshev@gmail.com
Hi,
-----Original Message-----
From: Stanislav Malyshev smalyshev@gmail.com
Sent: Tuesday, July 10, 2018 8:55 PM
To: Sara Golemon pollita@php.net; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] On not rushing things at the last minuteHi!
I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of quiet followed by
weeks of chaos every year around this time. This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.Yeah, I think it is natural (when deadline is closing in, people start to rush in), but
not good. And I would feel for big features, like typed properties or friend
classes (without touching its merits) I think they should target 7.4.In the future, I think the expectation should be that if you have a large
improvement it should not be expected to land in the version that is already in
the release cycle, even before feature freeze (especially if "before" is measured
in mere days). Large features take time to figure out and stabilize, and that
should be the expectation. So you can write the RFC and open the vote
whenever you want and whenever the life allows you the time to do it, but the
expectation of where it lands should not be "immediately", especially for big
ones.What is "big" is subjective of course, but deep language level changes (typing,
strictness, changing how major parts of language work, major language feature
like, I dunno, named arguments?) are big, and most deprecations or individual
function additions aren't.
I'm on the same page with Sara and Stas. There was a similar situation with 7.0 and the exception hierarchy changes. Even it was an alpha with a lot of other changes, there was a strong community demand and support. The feature was something completely new and different from the features establishing themselves over some years. That one however seemed dangerous for the stability. The decision was taken by the RFC vote, which had passed.
Some internal breaches are still allowed currently, while that is another matter in regard whether the user space functionality overwhelms. In some case, the internal stability concerning all the noncore stuff might be of more importance, sometimes it wouldn't. People might be busy and not get the RFC implementation earlier. Still, to keep the balance, IMHO we should have as a goal to have the feature freeze before the first alpha. Some nonintrusive RFC should be still applicable for the alpha or later, but a huge change should be excluded.
Particularly with the typed properties patch - I'm sure Nikita and Bob would stand for the follow up fixes. Github screams, that the community support is huge. The idea was also brought and discussed earlier already. I personally have a bellyache that this patch is brought that late and has some internal breaches. However there's the demand and the consent wit hRMs. We should rethink this kind of situation for the future release schedules and limit RFC to the time before alpha, in general. Limiting this to before alpha has sufficiently more buffer than limiting it before beta.
Regards
Anatol
What are the causes?
I have noticed three approximate (and overlapping) categories of late RFC:
-
Submarine features: Features which have been developed over a long
period, but where the author wanted to get things polished before
formally announcing, e.g. typed properties -
Quicky features: Simple changes which people have been mentally
working on, often just deprecations and edge-case handling changes -
Sleeping RFCs: Changes which enter initial discussion, go quiet, and
sit in "Under Discussion" without reaching a vote
In all three cases, I think the general psychology of deadlines comes
into play: it's easy to put off those finishing touches when you've got
plenty of time, then jump into action at the last minute. There seems to
also be a reluctance to target anything other than the current cycle;
partly just because "would you like it released in 6 months or 18
months?" is usually "sooner!"
One thing that might help, particularly with the 1st and 3rd categories
there, is a clearer set of statuses for RFCs and other features.
We currently have 61 RFCs in the "Under Discussion" section of
https://wiki.php.net/rfc; some of these are effectively abandoned,
others just need polishing and taking to a vote. Then there are any
number of experiments and TODO lists which could turn into a "submarine"
or "quicky" feature.
I'm not sure of the exact formula, but some possible lines of thought...
- Have a separate status, or a separate list (dare I call it a
"roadmap"?) for the RFCs targeting each release? - Include items on that list that aren't ready for an RFC yet?
- Find some way to prune that list at key points in the release cycle?
- Have some kind of inactivity timeout for what counts as "Under
Discussion"? Maybe a new status/heading of "Dormant"? - Have a "put up or shut up" deadline? e.g. if you announce a feature
targeting 7.4 now, you have to put it to vote by, say, March, not keep
it ticking over until next July
Regards,
--
Rowan Collins
[IMSoP]