replying inline
I think it would be helpful to have something like a roadmap with various > features and changes both in regards to language and features as well > as performance. > We have discussed before and the problem is the nature of the project: it is an open source project where the contribution comes from the spare time of the volunters (with a couple of exceptions like people from Oracle working on the mysql drivers/docs etc.). So we can try and plan ahead, but in the end we can only release what we have, and there are no guarantees that somebody will do the job (or do in in a reasonable timeframe). PHP6 was an example of a release where we didn't timeboxed, but feature-boxed, and I think that even without the unicode part, it would still take too long or would have to break some promises. Some of the open source project do something in-between, not promising exact features/ideas for a given release but selecting a couple of areas/aspects where the release should improve on the current situation: that could also work imo. > Also, having a clear line of when features will be deprecated then removed > will go a long way to help out users while writing their software. That > way, > people would know what to expect from the language and when it would > be the time to upgrade. > I think that it isn't necessary a bad thing that we aren't forced to tell beforehand than a given deprecated version will be removed in which version, because this way we can push the decision to a later date, when we have more information to select the best option. I think that Linus had a really good job explaining that in the first chapter of http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/ManagementStyle > > You could use the example of JetBrains and how they manage their > products via their issue tracker, http://youtrack.jetbrains.com/issues/WI > in which everyone that is not part of the core team can 'vote' for a > feature > or bug or what not and participate in a threaded discussion in a simpler > manner. This would bring you a nicer interface that the current ones while being > able to also gauge the community interest in certain issues. > We already have comments and voting (and ordering on the votes) in the issue tracker, but if you think that you can improve on the interface, feel free to send a pull request, I'm sure that there is much room for improvements, especially in the UI/UX part. > > I think if the PHP group would ask JetBrains for their software for free, > they wouldn't say no and I gave them as an example because I'm using > their beta software since it the second is out on their download servers > and I'm reporting every crash that I can as they made it really easy for > me to help them out. > Not sure how this is related to the discussion, but we already got some licenses from JetBrains (AFAIR Shein Alexey handled that for the phpdoc team). > > And yes, I do feel like the current software stack of PHP.net is a bit out > of sync with the modern tools that are already there, sorry if I offend > someone. > it is, and it is a chicken and egg problem: even though that the usual "my C-fu is weak" argument doesn't apply there, we still lack contributors, and the archaic nature of the current codebase doesn't really helps bringing in new people. even if a newcomer would come around with a rewrite of the current bugtracker based on some modern framework (ZF2/sf2/etc.), it would be a hard decision, because who who knows what new bugs that codebase has and there would be a real issue if the original author leaves and there would be no people left having familiar with the codebase. the current codebase sucks, but it had time for the bugs to surface, and the people who work on it are familiar with it. there is also an issue, that most of the php.net infrastructure is older than any other framework lifecycle would provide, so switching to a 3rd party framework would require more maintainence work (ofc. it would also have advantages like better documentation and people outside of the project would have an easier time to jump into contributing to it). > > That's why I think that the next major version of PHP should happen > sooner rather that later. I'm a strong believer that the current engine is > hard to maintain and document and very few people know most of it. > I'm a little bit confused, so you are talking about the PHP.net software stack or about the toolchain/stack used for the development of the language? I think that the current documentation team is doing a fine job (ofc. there is also room for improvement, like better/tigher integration/communication between the php-core and the documentation team), > > PHP 5.5 should be the last 5.X release then you should announce that > PHP 6 needs more volunteers for a better (faster) parser, people who > can help you on documenting it and so on. > I think that we definitely need to be more engaging for the possible contributors, making it as easy as possible to participate, and I think that the git/github move was a step in the good direction and the new php.net layout also. Closing the doors for 5.X without actually having something to release or at least a plan/roadmap would be a bad idea imo and the announcement you mentioned could be interpreted as a distress call, and maybe that is not something what we have or want. > > Just make PHP 6.0 a PHP 5.5 that's clean under the hood, maybe > even brings some performance improvements along the way and that's > it. Yeah, that is something what everybody would agree to have. I mean who wouldn't want more robust/stable and faster code. > You already know what are the requirements for everything, you > already have feedback on what the community wants in the future, > so why not help yourself by doing something that's clean and along > the way will help you get more contributors? > I'm not sure about this, some of the stuff that could/should be done (unicode support, AST based parser, etc.) is pretty hard, so we still need to research/prototype it, and we yet to find a way to get feedback from the community at wide (even the framework users conference attendees active community members are only a small part of the php ecosystem), there is currently a separate thread discussing that topic and proposing using surveys to solve this problem. thanks for your feedback! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
