** Feedback To start with I would like to address some of the feedback I got from my "Not in Symfony2.2"[1] serie:
- This is just an other rant, - Why don't just just submit PRs instead of writing this serie ? Most of the articles I wrote are about subjects that had already been discussed with some (if not all) of the members of the core team and no agreement was found. As those subjects seem important to me, this serie has been a way to share them with the community. I think it was useful as some actions have been taken: - A better documentation: Ryan has submitted a PR about improving the contribution page[2], - A (real) issue tracker: Bernhard is working on defining a process for the usage of the GH issue tracker, - A list of known issues: Fabien agrees to have such files[3], - A comprehensible security configuration: The issue has been fixed using option 1[4], option 3 is under evaluation I did not expect all of this to happen. Most contributors are volunteer and everything can not happen overnight, it takes time to discuss and implement solutions. However for one more time, I have been impressed by the reactivity of the community. To close this subject, I would like to say what I really think: Symfony2 is a great framework - which is why I use and contribute to it. But I also think that it could become better, mainly by improving our process. The good thing about the current process is that it is very light. I have also worked for some companies where the process was so heavy that is was a barrier for contributions, this is something we do not want. Symfony2 is great and there are some other great frameworks from the competition, we could get inspiration from them to know what works well and what does not work. ** Release schedule I am not really happy with the current release schedule[5]. Let's look at the release process of Ubuntu as an example as they do also have a 6 month release cycle. They start each release cycle by defining a plan of what is important to have for the coming release before starting their development phase. At the end of the development phase, there is a stabilization phase before the release. For LTS releases, they have a shorter development phase and a longer stabilization. There are some similarities with the release schedule of Symfony but most interesting are the differences: - We don't start with a plan. It means that our development does not really begin at the start of release cycle but can span over multiple release cycles - you can see this by looking at the amount of PRs that are already pending for 2.3, - We don't have a longer stabilization phase for LTS releases. This becomes even worse if you consider the planning: the 2.3 LTS release will only have a 1 month development phase and a 2 month stabilization phase. Don't forget that 2.3 is our last chance to get most things right as any BC breaks will be rejected after 2.3. One more thing is that we are now a little bit more than 1 week into the stabilization phase of 2.2 and Fabien as mostly merged enhancements. I am OK with that, I don't expect that we get everything right at first, but we need more time to polish the process and draw lessons learned. One thing we could do is to release 2.2 as planned at the end of February and delay 2.3 LTS until November - that would be a 8 month development phase and a 3 month stabilization. Could we really ask third-party bundles to upgrade to 2.2 in January and February, introduce new BC breaks for 1 month (some of the BC breaks will be deprecations in 2.2, some other will be introduced at the start of the 2.3 development phase) and upgrade again to 2.3 during April & May ? What does the community think ? Please no +1 / -1 alone, I would really prefer to hear about the impact on your application first and then about the big picture (would it be good for Symfony, the ecosystem, ...). ** Predictability One other major topic I am not happy with the the predictability of the releases - in term of content & quality. There are two major things that IMO can be improved here: - define plans - this has been discussed before in the serie[6] and above so I won't discuss it again, - have a better predictability on the available development resources - As Fabien said[7]: "How would you put a plan together without knowing who will be able to help? That sounds impossible to me" Fabien is true, most Symfony contributors are volunteer who submit PRs on an availability basis and it makes putting a plan together very hard. One solution that should be worth exploring is to create a "Symfony association" - Typo3[8] and Drupal[9] have such associations. The goal of the association would be to do some fund raising in order to be able to hire some developers to work on the Symfony framework - I don't exactly know the goal of either the Typo3 or Drupal associations but I would like to hear form them. It could be more than fund raising only. The association should accept donations from individuals or companies (same as the different levels of membership on the Typo3 association homepage) or ask "big" users to have some part-time dedicated resources working on some important features / fixes / documentation chapters. It would also mean that Symfony becomes detached from SensioLabs but I don't think it is a problem: if the association reaches its goal of making Symfony better faster then the adoption rate should increase and SensioLabs could sell more development, support and consulting services around Symfony. I haven't been thinking about this for very long but may be that is something to consider ? What do you think ? [1] https://gist.github.com/aa9df0383848e86af7ad [2] https://github.com/symfony/symfony-docs/pull/2138 [3] https://github.com/symfony/symfony-docs/pull/2137#issuecomment-12257339 [4] http://symfony.com/blog/security-access-control-documentation-issue [5] http://symfony.com/doc/current/contributing/community/releases.html [6] https://gist.github.com/aa9df0383848e86af7ad#file-roadmap-md [7] http://symfony.com/blog/symfony-2-2-schedule-update#comment-18077 [8] http://association.typo3.org/ [9] https://association.drupal.org/ -- -- If you want to report a vulnerability issue on Symfony, please read the procedure on http://symfony.com/security You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
