Monthly Archives: September 2010

CDT Summit Report: What to do about the Eclipse Platform

We had a lot of heated debate about what to do with the Eclipse Platform and the troubles we’ve had trying to contribute to it to allow it to meet the needs of our customers. There have been some successes, there is no doubt. We have flexible resources in 3.6. We have flexible debug in the platform for quite a while now. So we are very thankful for that.

But we’re still not in a good place yet. We’re still really struggling with build. CDT builds are complex beasts involving external compilers and linkers and other utilities and generators. Builds tend to take a long time. My standard sized C++ project porting the Irrlicht game engine to Android takes about a few minutes to do a full build with a Minimum 3-5 seconds for a one line change. It’s not “instantaneous” like Java and dynamic language builds tend to be. So features like automatic builds never made sense for us.

Also, our builds tend to be managed by external tools, ‘make’ in particular, that manage the “delta” of what needs to be built for us. The resource delta that the platform provides is useless in those cases, other than as an indication that something has changed and we need to invoke make. Mind you we tend to always build anyway just in case we have external files that may change that aren’t being tracked by Eclipse.

That leads to the oddest workflow, clean, which in the C++ IDE’s we’ve used in the past, means just that. Remove all previous build output. But since that also clears out the Eclipse build state, it invokes a FULL_BUILD right away to rebuild it, which we then interpret as the need to call out to make which then puts the build output right back. And if we ignore FULL_BUILDS, we miss the initial build. It’s a mess.

The good news is that we have people working on fixing these things, and have opened bugs against the platform and attached patches to them. But it’s been really slow to get them looked at or they are being rejected outright. What ends up happening is that vendors fork the platform and apply the patches they need anyway. Now that’s not a healthy situation when we are trying to build an ecosystem when everyone has a different eclipse platform you need to plug into.

So what do we do about this? Is e4 the answer? No. In fact surveying the crowd at the CDT summit, no one was interested in the features that e4 brings to the table. It doesn’t address the problems that we as a C++ IDE community have today. And we need to those things fixed in the Platform today, not in an incubator. Fancy UI frameworks are maybe something we need down the road, but our customers want us to get the basic workflows working well first.

So in a drunken stupor (well stupor anyway) at our celebration event I threw out a proposal to the people standing around me and then to others during the week. e4 is a fork of the platform. It was created to try out some new ideas. Why don’t we create our own fork of the Platform focused on meeting the needs of the CDT community and for our fellow Tools projects that have the same needs. That way we can at least share the forks we’ve already created for our products. We still need to run all the same plug-ins we do today such as Mylyn, JDT, etc. So we can’t go crazy and change the world. But at least we’d have control over it to make sure it meets our needs.

You know me by now. I like to brainstorm with the community. So I’m only semi-serious about forking the Platform. We are taking a serious stance on the bugs we have opened up there and I hope the Platform team will work with us for the mutual benefit of our users. We are frustrated about the lack of progress and we do need to think of alternatives. And forking the Platform isn’t as far fetched as it once seemed. It’s actually a admission of what many in our community are already doing.

CDT Summit Report: No git for us, not yet

We had a pretty good discussion about using git for managing the CDT source. For the community members that care, git is critical to the future success of CDT. git allows the workflows we need to allow adopters to make local changes as necessary and then deliver those changes to the CDT project as candidates for inclusion upstream. That workflow is very difficult with CVS since it requires you to set up a disjoint repository. Bleach.

So we’re pretty eager. However, at the end of the session, I got the feeling that we just weren’t ready for it. At least not yet.

First of all, there’s just the need to figure out all the workflows we want to support. I was excited at the beginning of the summer about using Gerrit code review for CDT just like the egit guys are doing. Having a system to manage code changes, to make them visible to all, and to make it easy to do code reviews, is very compelling. However, it turns out that the egit use of Gerrit was a trial and the Foundation staff isn’t ready to support it yet.

So we need to go back to square one, managing patches in Bugzilla which takes away from that fork and contribute workflow that’s bringing us to git to begin with. It does bring up the need to produce some documentation so that we can decide how we want to work and to educate the contributors on that.

That brought us to the egit plug-ins. There has been some really good progress with egit thanks to the team working on it. I’m using egit for a number of projects I’m working with, both Java and C++ and am really liking the experience. However there are still a few things lacking and defects that I’ll be raising bugs on. I am seeing a lot of exceptions when doing merges, including out of memory. I want to be able to compare branches, but I guess that’s what the Synchronization view is trying to do. But then the usability of the Sync View is very confusing.

And finally, the real show stopper for me is the lack of being able to create patches between two commits, e.g. between two branches. Again, our big workflow is to allow adopters to fork and contribute the results back to the project. They will be creating local branches and committing updates to them. So being able to create a patch between their branch and our master is a must.

At the end of the day, we’re just not ready. Once we figure out how we want to work with git, and when egit fully supports those workflows, we’ll jump on the bandwagon with both feet. Until then, we have work to do.

A great CDT Summit 2010

After a year off due to lack of travel budgets, we held the CDT Summit again this week this time at the Ericsson offices in Montreal. It was a great summit and proves again why we do these things. Many times I looked up during the meetings and then through the evening events and saw people from different places talking to eachother, laughing, sharing stories and experiences. You hold these things to have technical discussions on the issues of the day and plans for tomorrow, but the real value is the relationships we build working together face to face. You just can’t duplicate that on-line.

Many thanks to our hosts at Ericsson, Marc Khouzam and Dominique Toupin who worked tirelessly in the weeks leading up to the summit and fought through all the infrastructure issues you end up running into during these things. It all worked out superbly in the end, despite our ribbing them about it :). Thanks guys!

Also thank you to our sponsors from Ericsson, Eclipse Foundation, Wind River, Texas Instruments, Mentor Graphics and Google whose financial contributions made this all possible. We had a very special event on the first night and got a sense of the history of Montreal and a party in a unique setting. Not to mention the superb meals we had for lunches and breakfast, to fuel our efforts during the summit. It really made us comfortable and let us focus on the work at hand.

I have a lot to write about on the topics we discussed. There was a wide variety and some of these things will be of interest to the general Eclipse community as we work to make the Eclipse the best IDE for C/C++ developers in the industry, which is not always an easy task given the general nature of Eclipse. But I’ll blog about those things over the next few days.

My biggest thanks go to the 30+ people and their employers/sponsors who allowed them to travel and take the time out to contribute to the CDT summit and to the handful of people who attended remotely through my CDT conference bridge and Webex account. These summits are most successful when the people come with the mind of working with the rest of the community to do something greater than they can do on their own. As I mentioned to James on his way out. It’s why we do open source: “to have some fun and to change the world”.

More later…

Entering the Realm of Interaction Design

I’m about to embark on a relatively new era in my career. I’m always looking for new challenges and there is a huge need with the tools I work on to improve their usability. UI design is a long way from C++ parser writing, but I’ve seen great UIs and I know pretty quickly what a bad one looks like. And I want to make the life easier for my users.

I was given a book written by Alan Cooper called, “The Inmates are Running the Asylum”. I only read the first couple of chapters but it really chimed with something I always had in the back of my mind. Computer programs are usually written by engineers that assume (or don’t even consider) that users think the same way they do. And Cooper has some pretty good and common examples of where that assumption ends up being pretty embarrassing. Or worse, “it leaves the user feeling pretty stupid.”

When you work on a UI feature, often you’re following the Model-View-Controller paradigm. Being a computer person, you start with the model and then think of ways of showing that model to the user and then controls for manipulating the model. You want to make sure they can change everything to get the most out of the fine work you’re doing.

Well, the user doesn’t care squat about your model. He has a job to do. He is trying to accomplish some goal in order to look good in front of his customer. And he needs to do it quickly so he can get home to see his kids before they go to bed. He doesn’t have the time to learn the intricacies of your model and the esoteric ways you’ve provided to view and control that model.

Cooper suggests we need to do Interaction Design as a lead up to the actual code. Understand what the user is trying to do and find ways to allow him to understand your software quickly and to get his job done quickly. Design the View and Controller first, then worry about the model. Get under the user’s skin, know what he knows, feel what he feels. That’s a pretty tough thing to do for us engineers who love the challenge of creating the world’s best algorithms. You don’t need to empathize with anyone to write “good” code.

It’s a hard job to put together an intuitive interaction design that accomplishes what the user needs with minimal gestures, but I look forward to that challenge.