On November 23, 2015 10:10:37 PM GMT+01:00, Anatol Belski <weltl...@outlook.de> wrote: >Hi, > >it is sad to see that the discussion went in the direction it went, but >I'm glad to have missed that being away all day and at the end of it >realizing my mail server messed up. Please lets get the tone down and >discuss factually! > >I would like to turn back to the point I was depicting in my first mail >- the current stuff destined (including the bug fix for the sym table >issue ofc) into the 7.NEXT looks pretty much like a set of fixes for a >patch version. It is enough to go through the NEWS of 5.5 or 5.6 and >compare to realize that. In aforementioned NEWS files, several bugs can >be evaluated even as more critical as the subject caused the >discussion. An accusation that the intention to deliver this as GA has >the purpose of something bad has therefore just no objective base. In >opposite - looking like a patch release is a testimony that 7.0 is ripe >enough to enter the routine life cycle. > >Today, we have a set of patches that can deliver a stable 7.0.0 to the >today's knowledge (remember also 5.x NEWS files in conjunction with >this). I probably just repeat what I was telling - any known app >compatible with 7.0.0 today has the tests green today. > >To comply with the above and the definition of stable. Now, with >7.0.0. The gap between 5 and 7 is big, the number of >ported apps is small, same with the number of developers using it. How >do we get the wheel to spin? Please think strategically. How do we get >the 7.0.0 GA to have the gap to be the same as between some adjacent >PHP5 minor releases? > >Short - one can delay. There is a group of people who wants it to be >done. What does that mean? That means, less usage, less testing, slower >bug discovery. Even shorter - one can release. What does that mean? >That means that we are on the track, more apps are getting ported, more >people use it, more bugs we fix - we are stable. > >Just to remind - the RC7 was caused but the exact reason that it were >impossible and extremely bad to deliver an untested lot of various and >partially bad issues. And that was suitable. That's why also other two >weeks was taken. It is quite pointless to have a one week RC, because >the feedback on that is negligible and consequently no real bugs are >catched. It doesn't comply with the expressed intention to validate the >bug fix. Now, it is of course the matter of the definition, but issuing >one more RC for the bugs that are don't even stand near the cause of >the RC7 doesn't sound like an appropriate action. Either the bugs are >heavy weight and the fixes need to be properly tested, or they are >not. Except one turns back to the thesis that there should be no bugs. > >So in the end, a solution is wanted. I don't think any opinion is >allowed to be ignored for such a topic. So options > >a) release on 26th including all known bug fixes >b) do RC8, assume there are no bugs, so target 10th for RTM >c) do RC8, release on 3rd, expect there are no bugs come in >d) continue issuing release candidates till it's stable enough (needs >definition of stable and probably an RFC) > >I would really ask to reach a consent on either a) or c). IMO, the >options b) and d) are the direct road to curbing 7.0.0. There is no >hurry to release just to release, but it is definitely harmful to slow >down the ris...
I think a is best but c works too, although it makes no sense really... cheers, Derick, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
