Friday, May 27, 2011

The awesomeness of Eclipse Development Process (part 2)

Chris has asked for "concrete example" showing the real story behind my previous post. My example will be Tycho IP review. (Note: I'm an outsider to the whole process but I'm dealing with a lot of Maven/Eclipse/Tycho issues in Fedora).
Here is the bug with a lot of info in it. And now let's show the amount of changes that happened to Tycho codebase after this bug was open. I'm not sure that all of these changes are thanks to the project moving to Eclipse.org but I'm pretty sure that most of them are provoked by this and commit messages as this one seems to prove me right.
  1. Even the first few comments are showing that with the start of the review licensing has been fixed in a number of places. This might not look important to pure Java guys but issues like that are showstoppers if one wants to use this tool for something shipped with Fedora or Debian (the two distros with biggest influence on Linux developers). Examples here, here, here, here and here.
  2. No more checked binaries in the scm. Examples here and here.
  3. Cleanup dependency chain. The biggest sin of almost every java project! Examples here, here, here and here.
  4. Do not duplicate code/functionality. Examples here, here and here.
Some of the examples are falling in more than one group but they are mentioned in one place only, decide for yourself whether they apply for others too. Also note that these examples are taken only from git log so one may even think that this is just the top of the iceberg or that could have happened without Eclipse being involved at all. But there is evidence that at least few of them are thanks to it.

P.S. Tycho devs - keep up the good work - you have really made a huge change in the Eclipse ecosystem and I really appreciate your efforts. You are just the most recent show case for this post. :)
P.S. 2 If someone tries to say that these problems are only in certain projects I would ask him/her in advance to give us the URL of his project so others can point similar problems. 

We all do these mistakes and that's where we need help of entities like the Eclipse Foundation.


Let he who is without sin, cast the first stone

Wednesday, May 25, 2011

The awesomeness of Eclipse Development Process

The Hudson proposal to move to Eclipse started a big discussion about the Eclipse Development Process, IPLog/IP team and etc. A lot of people are complaining about the amount of work they have to do but having done few Eclipse Linux Tools releases I don't find this work that much, probably it hasn't costed me more than a day with non technical issues.
Now I plan to explain why is to so awesome to follow this process and respect it (note that I'm a Linux distro guy so I'm heavy biased):
  • every single bit is properly licensed - One can not imagine how many times we(Fedora) have reported/asked upstreams to at least put some license to their work! And this is a blocker for inclusion in the distribution and we have spend a lot of time patching out such bits and dealing with the consequenses of these actions. +1 for the Eclipse process here
  • incompatible licenses are not used/shipped together - One might think that this is just to make lawyers happy but this is only half the truth. It is also about respecting authors wish - if I choose to license my work under BSD I want people to use my work whenever they found it possible but if I choose to license under GPLv3 my primary goal would definetely not be the same and I would care most for people giving back. Most probably library developers would not gonna sue you for using incompatible licenses but this is pure DISRESPECT TO THEIR WORK. I can name a huge number of Java projects that don't even understand that. +1 for the Eclipse process too
  •  reduce duplication (side effect) - One of the recent reviews of the IP team made one project remove code that was already done in one of its dependencies. Most probably just to not bother with getting it IP clean. I don't know what would readers think but this is pure technical win!
  • remove unneded dependencies (side effect) - Same review as the previous point - a number of unneeded dependencies were removed just to not bother with getting it IP clean (if possible at all - read the first point). And the build was failing without these deps despite them being unused/unneded. Another pure technical win thanks to the IP team!
There are a lot of other benefits that can be mentioned but just the first two are making us - Java packagers(I'm sure I speak for at least few others) want every Java project to go through similar process. This would make packaging Java software a lot easier, a lot more acceptable and not that allien on Linux systems.

Kudos to Eclipse's IP Team 

Everyone actively working on some Java project - think whether you want your software to be included/shipped to a lot of users. You may achieve that yourself but having a team helping you in this is definetely helpfull.

P.S. Links and people/project names are intentionally not used to prevent someone getting it personal. :)