This is to support the guys back in my country who really are dedicated to this platform. Hopefully this association is going to make the Italian Drupal community stronger and larger, and I also hope to stay much more in touch with the Italian community despite living abroad.

Let’s keep in touch guys, and good luck to everyone.

All in all, it was a really good time and I will miss the guys. But it’s time to move on (yesterday was my last day), as first step of a long term plan (which of course I am not revealing here ).

All you need to know is my next step (which won’t make my plans clear at all ).

Since the author maintains the translation via GitHub, I just forked a branch that has already been merged back by Drew Strojny.

So, in the very rare case you are both Italian and want also use that theme on an Italian blog for Italian people, well, you are ready to go!

For a long time I never had the chance to contribute “seriously” (just some little patches here and there) in the community, but now different working conditions allow me to do so. This brought to my attention some issues in the community attitude. And when it comes to social attitudes, I am not an easy person to deal with when I get disappointed.

Maintainers can decline patches for any reason

All started with me trying to contribute a patch to the Content Copy module. You can read the whole thread as well as some of my recent posts to know about all the technical implications.

However, here I’ll be focusing on the political/sociological/philosophical aspect of the matter. I won’t talk again about avery single disagreement, but just about the most important fact: markus_pretrus refused the patch for no valid technical reasons, but just for personal concerns. He never brought a valid counter-example that proved the patch to be dangerous, he was just afraid the patch could cause harm somehow.

(In addition, he later said that I should have used CRUD APIs to update a content type and not the import procedure, never realising that what my patch did was to use CRUD APIs to enhance the import procedure and making it able to import a new content type definition into a pre-existing copy).

So, the point is: if maintainers have personal concerns not supported by any proof, they are still in the position to refuse the patch, whereas the correct behaviour should be to accept the patch, test it extensively, etc. etc. We are still talking about software, after all.

Chain of trust might be dangerous

The usual chain of trust we find in communities might be dangerous in this case, as it happened that someone else found perfectly reasonable the markus_petrus’ argument. This, of course, led to the situation where my CVS application to publish the Alternate Content Copy module (a module created out of the patch of the discord) was refused. The reason was simple: such a contribute is supposed to be a patch to the original module, not a module itself, and that makes sense. But at the same time the patch won’t be accepted. Deadlock.

The CVS application process flaw

All the story above led me to realise the big flaw of the Drupal CVS application process. They have some conditions to be respected in order for your application to be successful. And to be honest, they make sense. What a pity, though, that once you’ve got your CVS account, you can create as many projects as you want. First of all, this doesn’t make sense; secondly, it makes too easy to bypass the conditions for the application: all you have to do is to take over an abandoned module (easy) and apply for a CVS account (that you need to maintain the module you took over).

Conclusions

I am sure that everyone in the community has got the best intentions, but when a situation like mine shows up, it makes it too easy to mutate a community in an oligarchy. Also, having such a flaw in the CVS application process, makes several efforts worthless.

Please, refer to the “Windows” section within the README.plus file to know how to compile the library on Windows using Visual Studio.

The backport this time was very easy, because there were no major changes. Python tools have been updated as well, and now they should work with Python 3 too.

On the “Plus” side no changes have been made, except some tiny bug fixes. One note, that you will find also at the bottom of the LIBSVM Plus page, is that now LIBSVM Plus is hosted on Github too.

Enjoy, test, and report!

PS: at the risk of losing credibility, I’ll remark, once again, my intention to rewrite this software. I swear I have made a decision this time: it is going to be rewritten in Go. I have already started playing with the language (soon some posts about it) and designing the new software.

In that article I explained the general reasons why those modifications should be part of the official Content Copy module.

Now, I do realise that Fields in D7 might be so different that everything I am about to say could not make any sense in the near future. However, I would like, with this article, to explain why the programmatic update of CCK content types does benefit of my modifications.

Programmatic CCK content types update: Markus’ way

In another post I explained how to get programmatic CCK content types done, including a programmatic update. My way of doing this last bit only works if the Alternate Content Copy module is used.

Markus_petrus claims that my way is not the safest and the correct one to go about that. Instead, in the hook_update_N() the CCK CRUD APIs should be used there where the Schema APIs would be used for regular Drupal content types.

Basically, the procedure suggested my markus_pretrus can be summarised as follow:

• Update the content type using the UI to reconfigure the structure and export the new definition to code (the .def.inc file in my example);
• Write a new hook_update_N using CCK CRUD API to resemble the new definition.

At this point both a fresh install of the module or an update of it should take us to the same version of the content type.

This is fine and it resembles exactly what one would be doing for a regular content type:

• Update the content type schema within the hook_install;
• Write a new hook_update_N to resemble the changes made to the schema definition at the previous point;

My way: less error prone

By using my solution to implement CCK content types update, we can improve things in two ways.

Firstly, we make the updates less error prone, as both the hook_install and the various hook_update_N would be relying on the same content type definition, and there is no way the update procedure and the installation procedure could end up with a different result. There is no CRUD API (directly) involved, so no human error can occur while writing them into the hook_update_N that could make an update be different from a fresh installation.

Secondly, we make the job easier for the developers, because everything they need to do is to export the new definition to code and then add a new hook_update_N that will have a standard format, i.e. all the hook_udpate_Ns will look the same.

CRUD APIs vs Alternative Content Copy. Really?

I have been writing this article so far because of a supposed divergence of opinions about how to implement CCK content types updates programmatically. Well, whether you believe it or not, that is all an imagination.

My modifications to the import procedure you can find in the Alternate Content Copy module make exactly use of CCK CRUD APIs. Also, I have been comparing my solution to the CCK_sync module. At the end of the day, we do exactly the same thing, but the latter has been referred to as one possible way to go for those who require a proper update of the whole content type.

The only real difference between CCK_sync and Alternate Content Copy is that the former provides the functionality as alternative functions to be called via code and/or a separate interface for “synchronising” the content types via UI. My solution, instead, alters the already existing functions and APIs, integrating into CCK seamlessly.

I still believe my approach is all right and I would dare to say even suggested, as the import procedure of CCK Content Copy should provide a way to perform a complete update of a content type, that is erroneously called synchronisation by the CCK_sync module.

Nevertheless, my full update functionality is provided on top of the already existing functionalities in Content Copy, which means you will still be able to create a brand new content type (of course) and also to import just new fields in a pre-existing content type.