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