Kepler retrospection - was CBI a net loss?

While I was reading Kepler retrospective notes, I found this statement:

CBI was a net loss for us so far. It was a very large volume of work just to get our build back to its old state. There is benefit for others in the community to make it easier for them to run builds independently. For committers it hasn't delivered value yet.

and started immediately wondering who was the "us", and why it was "a net loss".

Fedora had it's own Eclipse build system, which was 8 x faster than current CBI build (15 minutes vs 2 hours on non-SSD drive). I've spent a lot of time getting Eclipse built with Fedora and switched to CBI before the Foundation did.

All that was (and still is) a cost, but was it really "a loss"?

I find it rather as a first step towards a really necessary move - Eclipse Foundation taking responsibility on development. The build system is first, then maybe we will get vendor-neutral architects or UX designers.

Another point is that once it is possible to easily rebuild Eclipse, we can see even right now internal Eclipse teams appearing here and there, which tend to become really valuable contributors.

Not to mention that after Kim left, it took about a month to get builds running again (at the Eclipse Foundation, we had them running in Fedora). Is it ok to have so much power depending on one person (because that is what happens if you have a large ant-based build)?

I'm sorry but I can't agree with a "net loss". It was a necessary cost. Good for the Eclipse Foundation. Good for the Eclipse.

BTW. I really hope some day UX designers or architects will be hired by Eclipse Foundation.

Cascaded builds - solution or a problem?

Fedora 19 consists out of approx 14000 of packages. Could you imagine a situation, where a security fix for one basic package (let's say kernel) would cause a need for the 14000 packages rebuild*?

It sounds strange.

On the other hand, it is perfectly normal in the Eclipse world. Let's imagine that I want to put a new EMF into my Eclipse platform. So I need to build EMF, and put it into Eclipse (a.k.a. rebuild platform with proper update sites). The whole process takes quite some time, but that's not that important.

If EMF had any dependencies, I'd have to rebuild them first.

So I've started investigating how to automate those tasks. And this is an answer I've received:

[...] From my point of view, these Java module frameworks refuse to acknowledge that  there is extensive experience with distro-level release engineering. (Basically, exact dependencies and multiple versions of the same code might be convenient now, but will seriously hurt you down the road.) [...].
Florian Weimer.

Full text in the fedora-devel.

The part about strict dependency check struck me as being "just right". Eclipse definitely needs a very strict checking at the build time and during changing the installation.

But it does not, and should not be very strict about components being changed at runtime.

And yes, rebuilding the entire Eclipse to get a minor security update in one of it's dependencies is a waste of time.

So I've put up a small wiki page in which I described how I'd like to see installation handled.

The link to the wiki page.

Any comments welcome.

* such situations happen, although very rarely, especially when there are big changes done in compilers, but this happens only when a distro was not released yet.

EDIT: corrected typo and link to fedora-devel.

A nasty bug in dropins - read it if you use them

The nature of dropins is that they were supposed to be a transitional mechanism between old update manager and P2. Dropins have more advantages that they were supposed to have, and one of them is truly easy management - just copy a plugin, and it will work (in most cases).

This time, however, a really nasty issue managed to get into Kepler. It was discovered about two weeks ago, when some of our Fedora packages started disappearing after updates.

We often get similar issues before final build of Fedora is released, so it did not looked seriously. But after a couple of days of checking our build process and testing I've found that:

If you deploy into dropins a plugin that is already installed using P2 director, your Eclipse goes bananas, especially if this plugin is a platform dependency.
The dropins mechanism will try to uninstall it, and then, depending on your configuration, will stop working, or will break your Eclipse.

The bug was reported in the Eclipse bugzilla, but it will most likely be shipped due to the bad timing in which it was discovered.

So beware of what you put into dropins - unless you want spend the same amount of time that I did trying to understand what's going on.

EclipseCon France - Wrap up

I had a pleasure to take part in the EclipseCon held for the first time in France. Here are is my main observation:
Java has more in common with javascript than continental breakfast with breakfast.

Also, for the first time, there was a true coming out of people adjusting and packaging inhouse flavour of Eclipse. A few of my live-recorded tweets:

Cern devops - a new major version cant mean starting over.
— Christopher Daniel (@kda) June 5, 2013

.@prapicault's talk: 10000 people spending 5 minutes troubleshooting Eclipse is a cost.
— Christopher Daniel (@kda) June 6, 2013

Yet another presentation saying that standardization is required if you want to scale up your dev team. There is future! #eclipsecon #devops
— Christopher Daniel (@kda) June 6, 2013

So, it's all about having a few people in an organization that know tools, and prepare tools for others. It just looks like the idea of "bring your own device" policy was wrong. A corporation needs standards. Period. And it's much better to have a team designated only to free software management than allow your employees to invent the wheel again and again.

I wish all those eclipse builders contributed back!

What's more, I believe that the future belongs to those small, single-purposed IDEs, and kind of natural consequence will be equally precise a IDE in the browser, where you rather point&click required solution rather than spending a couple of days figuring out how to set up certain tools to build a server app and then a mobile app. Ideally I'd like to be able to say "yes" to this tweet:

@RickBullotta @kda @mmilinkov cool. Can I write and debug my native mobile apps that talk to my node server?
— Doug Schaefer (@dougschaefer) June 5, 2013

That's said, Eclipse was included into the Red Hat Developer Toolset. The Developer Toolset is a set of tools that work together, and are decoupled from the underlying base, so you will be able to use a stable work environment and up-to-date development tools, without configuring things by yourself!