On Mon, Apr 28, 2008 at 9:30 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Mon, 28 Apr 2008 08:46:03 -0500 Providing plans, sketches in a prominent place so that contrib could know where changes will be focused etc...
This is already happening in the issue queue.
I don't think it is a good communication strategy and a good development strategy to just say things will break and we won't care.
We do care. Look at how much work goes into any major, or minor, API change before saying we don't care. When 10-20 people participate in writing and reviewing major changes, plenty of diverse perspectives are taken into account. If someone says "this isn't worth the API change" or "we can get an equivalent improvement without the API change," and can back up their argument, then their ideas certainly will be taken seriously.
I think it is time to consider the drawback of things breaking... that doesn't mean things won't break, but that at this stage of Drupal life drawback are less negligible than they were used to be and that requires more "management", planning and a different communication strategy.
I'm not pushing for a revolution. I'm showing my needs and my feelings. I'm not a leading contributor, I just submit occasional patches and sometimes I help people on the ml.
I am the 5.x branch maintainer. At the height of development, I spent approximately 20 hours per week, sometimes more, reviewing patches, while putting patches I wanted to write on hold, keeping a day-job building Drupal sites, and sometimes skipping social things. I appreciate your contributions, no matter what size, along with everyone else's contributions. I have heard the whole "slow down the API changes" discussion many times before. Development is "slowing down." Release cycles used to be 6 months, lately they have been yearly. The introduction of tests in the 7.x cycle will either slow down or improve the quality of changes. Community self-regulation is working.
I think that having a longer support period for security is a good idea, even funding this support too.
Supporting long-term security releases without other bug fixes is a bad idea. I do not want to reject good patches, which people have spent time on, because a release series is unsupported and then go and make a security release anyway. Before I would consider maintaining 5.x beyond the planned timespan, paid or not, I would need to see a well-thought-out analysis of how it would affect the community as a whole, and agreement from the security team, core branch maintainers, and community. A few people saying they want something, which they are not personally helping with, is simply not sufficient.
It should be something that is going to happen naturally, but if you follow nature in a more conscious way, the path will be smoother with more satisfaction for everyone.
I am honestly not quite sure what you are substantively asking for. Should we go to our best contributors, who are out there improving the core APIs, and ask them to slow down and think about what they are doing, or rearrange their work schedule? Maybe add some paperwork to the front of any major task? I don't think so. They are doing great work. I have not heard major complaints from anyone who has actually used the updated install/update, form, content type, menu, database, or theme APIs. These are all changed for good reasons and the process generally works. Should we change our release schedule? We are already making the schedule test-coverage-dependent. Is this change no good? Do you have a better plan? Should we tell our branch maintainers, security team, and other contributors, to spend more time on older versions? If so, then other things will have to go, probably other Drupal contributions. I had hoped to be updating api.drupal.org this morning, but instead I am writing out a well-thought-out email about my job as branch maintainer. Sorry, now I have to either change my evening plans or everyone has to wait until tomorrow. -- Neil Drumm http://delocalizedham.com