On Mon, 28 Apr 2008 11:57:44 -0700 "Neil Drumm" <drumm@delocalizedham.com> wrote:
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.
It doesn't work for me. I don't want and I can't get so involved in Drupal core dev. It is over my possibility. There is drupal core, contrib, themers, users... etc... etc... I give great value to all the people contributing to Drupal... especially the ones that spend 20h/week (paid or not), but still Drupal is an eco-system. I may not be suited to this eco-system. Let me at least understand it. If you've to get involved into drupal core development and follow the issue queue to know which API are going to be touched or it will come as a surprise you may expect that it doesn't work for some people that still write code as you may expect that a DBA have different interests, competence, time schedule etc... than a python dev. Nevertheless a good app will require the collaboration of a DBA and a python dev.
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.
Then you've to rephrase one of the documents that is one of the manifest of Drupal.
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'd go a step further. I'd say: should we change this right now or should we wait we've enough resources to change it in a way that we won't have to change it again the next release cycle. I know that Free Software is driven by needs but that doesn't automagically make development rational or avoid clashing needs or avoid the need of compromises. Again... I'd like to point out that even contrib is more mature and there are modules that will require more effort than changing 30 lines to port them and that they support investments and that contrib and core are different and they may need to harmonize targets on a medium term horizon even if they have a common long term horizon. Not every contrib have to be involved in core dev to have a word on it, and the more the contrib part is complex the more the contrib authors won't have time to get involved into core dev, still contrib is growing in value. I'd like to avoid this things pass unnoticed because people don't see crowds of contrib getting involved into core.
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.
But... you're going to hear it again... since the future is not the past and the more the API mature etc... the balance will have to change.
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.
I noticed.
Community self-regulation is working.
OK... I'm part of the self-regulation ;)
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.
What's the problem? Provided there are resources (sponsors?) what's wrong with having just security fixes. I'm really dealing with projects that spans several months of pure development. Jumping on a dev release is risky (you need a stable API and you can't afford to fight with bugs) if you're a small shop. The stable release won't last enough.
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.
Absolutely.
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.
Considering that not all development in drupal is taking place into drupal core and that not all contrib may show up there.
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
Should we go to the contrib crowd that are adding valuable modules and ask them if they prefer to add new features to their work or spend their time porting their modules?
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.
Don't apply what was the past to what may be the future. I admit I may have been naive trying to evaluate the effect of fast moving API just counting contrib *files* for 5.X and 6.X but it may be worth to evaluate the effects, estimate the costs as Victor Kane proposed and do a pool across contrib and weight their response according to popularity and complexity of the modules. I've a reasonably large project I'll have to port from 5 to 6 or 7 depends on when it will be finished... I'll see if things are better than expected but I'm frightened to death.
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?
Did you miss I already pointed out all the things that are already going in that direction?
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.
Do not think that was not well-though-out and didn't require time that I could use for something else. -- Ivan Sergio Borgonovo http://www.webthatworks.it