Microsoft is shooting itself in the foot

So today I received a phone call from the Microsoft 'client support' (so called) entity.

It's pretty clear that they are more into following a process, even if it's totally stupid, than helping customers. (remind me Dr Strangelove, when the guy can break a CocaCola machine to get the 10 cents he needed to give a phone call that would have saved the world ...).

Instead of solving my simple issue with a simple solution (namely, providing me the KEY that is associated with the installed product, which is different from the product we bought - a Windows 7 premium. Probably because the DVD was badly stamped before being put into the box), they keep going insisting that we install a new version, losing 2 more hours plus having to reinstall all the side products.

Seriously, it's time to think about switching to some more friendly system, people. Ubuntu is quite usable, so is Mac OSX (but you might face the exact same problem). In any case, making 25% margin is just a shame when the UQOS (unquality of service) provided is so high : basically, you are on your own.

Coupled to the fact that they have delegated the first level support to external companies in low cost countries (profits, it's all about profits), it makes it pretty obvious that Microsoft is equivalent to what IBM was back in the 1990.

The butterfly is now just an elephant, not a dancing one... Sea elephant on the shore.

Maven release failures

So today I had to generate the MINA 2.0.0 packages in order to launch a vote. We have a full page on MINA web site explaining how to cut a release : http://mina.apache.org/developer-guide.html#DeveloperGuide-ReleasingaPointRelease%2528CommittersOnly%2529

I must say that Maven Release plugin is either totally dumb, or that what it does is totally counter-intuitive, and broken, IMHO.

What is the problem ? The maven release:prepare follows the steps :

1) Check that there are no uncommitted changes in the sources : OK

2) Check that there are no SNAPSHOT dependencies : OK

3) Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use) : OK
(here, we went from 2.0.0-RC2-SNAPSHOT to 2.0.0)

4) Transform the SCM information in the POM to include the final destination of the tag : OK
(the SCM info is now scm:svn:http://svn.apache.org/repos/asf/mina/tags/2.0.0, as expected)

5) Run the project tests against the modified POMs to confirm everything is in working order : OK

6) Commit the modified POMs : KO!!!

What's wrong here ? Everything has been committed in the trunk instead of the expected mina/tags/2.0.0 !

Why is the maven release plugin modifying the SCM tag if it's to commit everything in a place which should store the next version, ie 2.0.1-SNAPSHOT ?

I could understand that this is done on purpose (don't see a single reason for that, but who knows...), but at least, can't it *ask* the user before messing with the trunk ?

Sometime, the Maven Way Of Doing Things (tm) is completely broken, and this explains the complaints found on the blogsphere...