On Thu, Mar 5, 2009 at 4:08 AM, Ivan Sergio Borgonovo <mail@webthatworks.it>wrote:
On Wed, 4 Mar 2009 20:06:14 -0500 Khalid Baheyeldin <kb@2bits.com> wrote:
So far, it has proven to be an acceptable price to pay for innovation. Yes, it causes some pain, but if we fix the APIs
I think some more attention should be put on "so far".
I never read a book on software development that suggest that writing from scratch is a good strategy but I admit having felt the pain of refactoring quite frequently I've read more books on how to fix the problems rather than how to get involved in a completely new set of problems ;)
Most of the books are geared to corporate/commercial environment where there is a central authority directing everything, a limited pool of people resources with known skill levels to do the work, and a budget set by the business. This is open source where all the rules are broken: we have a larger pool of talent with varying skill levels, they do the work on their own as they have the time to do it, for fun or profit or both, and anyone can jump in and create patches for any project and ask for reviews. It does not have to perfect from day 1: it just has to be good enough and released early so others can refine it. I maintain/co-maintain 37+ modules (since I last checked) and it would be insane if I would have to upgrade them all. Instead, for a couple of core releases, people upgrade them as they need them and submit patches. It works wonderfully. Organized chaos! It could be that this is going to be part of drupal nature... since
it is a tool for a still very dynamic environment where the set of problems change quite radically... but still... I wouldn't take it for granted that drupal development life-cycle and nature is going to be the same as it has been in the past. For the same reason I consider the argument of "let's stabilise the API" a legit argument as well... and it is just a matter of balance and context. I think the evolution of how fast API are going to change will follow the evolution of how much core is an application vs. a framework. I think one of the secret for success of drupal has been being halfway between a self sufficient application and a framework. This is a ideal spot for small to medium projects where you can add value with some tuning and the cost of rewriting is lower than the cost of missing a large improvement made to core. But the space for small shops is shrinking and the complexity of the overall drupal project is increasing. I wouldn't take for granted that the sweet spot is always where it used to be and factor in as much elements as I could to make a forecast. Maybe core devs belongs to "subset" of drupal community that has "its own itches", but the efforts of core to "scratch their own itches" may not be the best compromise to scratch the "collective itches" of the community that is *evolving*. I'm not saying that core devs are blind or insensible to community needs, I'm just saying that it's better to take nothing for granted and somehow this kind of discussions aren't pointless just because they are repeated.
From what I explained, the "so far" is still valid, so need to change it for D7.
We always adapt and if we feel like D8 needs to change that, then we cross that bridge when we get to it.
Panta rei.
Orchestrating for this is one of the most valuable targets of software development especially in Open Source projects.
Better focus on tools that would make migrating your modules easier/quicker (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
Awesome. I've found http://drupal.org/project/deadwood That was easy. What were you referring to with "core"?
Typo. Should read coder: http://drupal.org/project/coder Again the best asset of Drupal is not modules, or code. It is the volunteer base. They will jump in and upgrade stuff for you as they need it.
Do you have any other pointers to tools, docs, secret recipe, everything that will help to port modules?
Help the modules you care about by submitting patches, testing patches, improving the README and other documenation.
I was just planning to write my own tool at least to spot changes in signatures.
See coder above. Help improve it if you like it.
Are there any coding standards that could make porting easier? Core dev strategies that could make any change easier to digest?
Again, coder checks a lot of that.
Maybe Kyle Mathews is right and we just need to try and all the tools, docs and efforts from the core team to make transitions as smooth as possible are already there... but is there some further knowledge, tool, strategy that could be deployed? Or just a linden tisane?
Perhaps a guide in the hand book will help: "a quick guide to upgrading modules from a previous version to a current version" with all of the above info and much more. Any volunteers?
thanks
-- Ivan Sergio Borgonovo http://www.webthatworks.it
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci