Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85624
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.172 as permitted sender)
Message-ID: <551B8FF1.7080002@gmail.com>
Date: Tue, 31 Mar 2015 23:28:01 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Julien Pauli <jpauli@php.net>, Ferenc Kovacs <tyra3l@gmail.com>, 
 Michael Wallner <mike@php.net>,
 PHP Internals <internals@lists.php.net>, 
 Stanislav Malyshev <stas@php.net>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>	<55193060.5000804@php.net>	<CAH-PCH6Q7FA536v8qABLSC9C2C0ufXOo2e0eWcB2QfJcLv+gSQ@mail.gmail.com>	<CAMUwpuRYMxX9paP0y0-DHAdX4=TX7qeO8wS7Q_9QsU+A3x-rPw@mail.gmail.com>	<55199AE8.4090100@gmail.com>	<CAEZPtU6G1xfEeAu0UfRN5kWr_4erpRZ4-Nz_1RtRBYMyHWh3Pw@mail.gmail.com>	<551AFC1E.6010501@gmail.com> <CAEZPtU7994SebJOkjpDyinti=RYXSwBWp4=h5sF0nUJka_aT4A@mail.gmail.com>
In-Reply-To: <CAEZPtU7994SebJOkjpDyinti=RYXSwBWp4=h5sF0nUJka_aT4A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> That one is rather easy to follow and disallow any kind of bully pushes.

"Easy to follow" != "good to follow". I have no idea what you mean by
"bully pushes".

> Which years are you referring to?

The ones that will pass between feature being contributed (which if
enhancements are banned in released versions will have to go into 7.1
once 7.0 hits release cycle, which is very close to now, arguably
already happening) and the version containing the feature (that being
7.1 as per above) is available to the contributor for their project.
Note it's not the same as "released on php.net" as upgrades take
significant time to propagate, see 1% of 5.6 adoption. Optimistically,
the delta between 7.0 and 7.1 is at least a year, and since wide
adoption of 7.1 is not likely to happen in less than a year, thus plural
"years".

> with a couple of maintainers (of these distros) and they all like this
> new process and would like even more strictness when it comes to new
> features. Why? Because it makes their work easier, be testing,
> validating a new release for a LTS, etc.

I value their effort a lot, but with all due respect I'm sorry to say
that their work being easier is a lower priority than PHP being better
for the users. If the choice is between us working harder but PHP being
better and us working less but PHP being worse, then we should choose to
work harder. Same should apply to the middlemen between us and the
users. So I can not accept the argument of "let's ban new features from
PHP until 7.1 because it makes it easier to repackage PHP". I'd be glad
to make their work easier, but not at the cost of hurting the whole
project.

> So what you are saying is that now we are on track to actually improve
> new releases adoption we should not make it even easier? Or go

In general, we should definitely make it easier. However, what you are
proposing is not a good way to achieve it. It's actually a terrible way
to do it, as it kills all motivation for small-scale participation and
also decreases motivation to run latest stable version for people that
need some small thing that is added only recently. Since they can't have
it in realistic timeframe, they'd work around it and since they have
already worked around it, it no longer motivates them to upgrade.

> You brought the "even longer with 7" argument, 5.7 could have
> prevented you for having to wait "years" to get one minor features or
> another. That's all.

It would not help any, as you would ban adding small enhancements to 5.7
either (and, if I understood it correctly, 5.7 is to be 5.6 plus BC
fixes anyway), so 5.7 would be useless if I wanted to have enhancement
that might be introduced now, since, per your philosophy, 5.6 is closed
for enhancements, 5.7 is closed too since it's 5.6 + BC fixes, and 7.0
will be closed as soon as it enters release cycle, which is pretty much
any moment now. So if you want to add something like option to
json_decode, your first chance to have it is still 7.1.

> No comment. Pointless troll. I am the one keep saying that I do not
> like us using only WP to validate changes.

Yet you did use it as an argument, and call me a troll for pointing it
out. This is just rude.

> Chicken-egg problem, wait until people actually moves away from old
> Debian/RHEL and adopt recent ones. This is what I am saying since long
> and in the previous paragraph. Please at least try to see that.

No, what you were saying you want to ban enhancements now (unless I
misunderstand you, then please clarify it) - not in indefinite point in
the future when our last stable adoption is not 1% but much better. When
that happens - and I hope it does, but it did not happen yet - then we
come back to this and banning enhancements in released versions and can
have the discussions with facts available then. You may think if we ban
enhancement then people would jump to 7.x in droves - but I have yet to
see anybody taking decisions this way. So far statistics says people
still are in 5.3 and 5.4 massively - though we do not add features there
for quite some time. So it doesn't look like not adding features makes
people to move on.

> A blanket statement? We discussed that many times already, my stance
> did not change a single yota since then. I repeated it here once again
> to make it clear, and for the record.

Saying something many times is not the same as substantiating it. In the
last letter you did finally bring an argument for banning enhacements -
it makes the life of third-party packagers easier. It is completely
true, but it carries a very high price, and we should not pay this
price. I'm all for any effort that makes their lives easier, but with
the condition that it does not mean something as drastic as not allowing
small enhancements, which was always allowed since we started the whole
release process thing.
-- 
Stas Malyshev
smalyshev@gmail.com