On Wed, Apr 1, 2015 at 1:28 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: > 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.
How many % use source install vs packages? From which users are we talking about here? > 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. It is one of many arguments. Do not forget the other ones, which are as valid and important than the distros one. >> 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. What killed it was to reject 5.7, this was a mistake based on nothing but some random fears about not being able to finish 7 "in time". To make 5.6 the "all in" small features improvements in every 2nd patch releases for the next year is going to be good fun, for everyone. Remember? 3 years, that means we have a year to get all possible small improvements in. It cannot end well imho :) >> 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. I was against not having 5.7, and against 5.7 only for notices (sadly the RFC did not contain any other options despite agreements on that). My reasoning back then and this discussion proves it correct, is that we will make a mess of 5.6 because "7 adoption will be even slower". Solving zero of these issues but making 7.x adoption even slower and 5.6.x a features check mess. Not my idea of simplicity or not the best way to increase adoption by helping users and packagers/distros. >> 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. Again, see that when people moves to latest distributions versions as well. Distributions catch up recently with our release process and only latest releases have latest PHP. So yes, I do think adding enhancement in patch releases is counter productive. >> 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. No. Not only 3rd parties packagers. Users too. Not "which patch version has that?" hell. I said the atter many times too, including in this thread. > It is completely > true, but it carries a very high price, and we should not pay this > price. So you consider adoption the bigger issue here but one of the best way to actually increase the adoption pace is not worth it? Distributions actually providing latest PHP is what boosts adoption. > 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. And it went too far for my taste. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
