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