[development] How to port modules? was: Drupal 7 "When it's Ready"

[Khalid Baheyeldin]

On Thu, Mar 5, 2009 at 4:08 AM, Ivan Sergio Borgonovo
<mail at webthatworks.it>wrote:

> On Wed, 4 Mar 2009 20:06:14 -0500
> Khalid Baheyeldin <kb at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090305/abdb6347/attachment-0001.htm