June Eclipse Board Meeting Overview

For those who didn't know, there was an Eclipse board meeting last week. Ed has already given his quick synopsis of the meeting, but I figure I would try to give committers a general overview of what happened that's in their interest.

Intellectual Property (IP)

IP was a hot topic at the board meeting for the committer representatives. Ideally, all committers would love to see the IP process be as fast as possible and less confusing. To help with some of the issues around IP and committers, a new "IP Working Group" was established to get input on what can be improved. A couple topics for the working group are:

• How to improve IPZilla to make it easier for committers to use?
• Can the Parallel IP Process be used by all projects, instead of just incubation ones?
• Can we reduce the redundancy of legal files across Eclipse and its projects?

Another really important topic that came across was the issue of dependencies in Eclipse. The board recently published a document that discusses different types of 3rd-party dependencies ('works with' and 'pre-reqs') guidelines and how projects need to comply. In summary, the board is trying to prevent projects to depend on components that have a license that is incompatible with the EPL and provide no other way to get similar functionality. An example that illustrates this well is the EMFT Teneo project. Teneo allows for EMF models to be persisted in databases via its framework. Teneo allows for pluggable persistence providers like Hibernate and JPOX/JDO. If Teneo just provided the Hibernate provider with no way for other providers to be plugged in, that would violate the guidelines.

Proprietary Tools

The board also passed a resolution for how projects should deal with using proprietary tools. Committers should keep this in mind as the use of proprietary tools may unintentionally set a high barrier to entry for new committers on projects.

Committer Diversity

The topic of project diversity was brought up and how projects can attract new committers (if need be). This is a personal issue for me as I'm more concerned how Eclipse can attract more independent committers. In the end, this is something really up to projects themselves. Ideally, all projects should have an infrastructure (ie., good documentation on how to get started) that allows for committers and contributors to participate. Eclipse is doing some good things to bring in new contributors and committers to the fold. I'm really proud of the Eclipse Summer of Code work and I hope more projects continue to participate in this program. Also, there is work in progress to start a "Bug Day" for Eclipse which I plan to announce once it's ready.

Foxes

Oh by the way, Ed spotted a fox again.



Conclusion

On the whole, I can say that the committer representatives were very happy with the direction that the board meetings went. The board was very responsive to committer issues that were brought up, so that means if you have an issue, please post something and we'll do our best to respond. If you don't speak, your voice won't be heard :)

Culture of Collaboration

Collaboration, collaboration, collaboration... how high do Eclipse committers value it? Is Eclipse missing something to help us as committers collaborate better amongst each other? I personally think so, especially after talking to some committers at Eclipse Forum Europe last week. Let me use an example from the field, there's a nameless independent committer on the Modeling project who has to use Skype, MSN, AIM, IRC and Yahoo just to communicate with his teammates (in real-time). From my point of view, that's kind of painful. For people who work in large companies where the committers on the project are mostly from the same company, it's not a problem since you have your own internal messaging system (I personally take this convenience for granted).

In my opinion, in order for Eclipse build diversity in the future, we need to create a culture of collaboration. To put it simply, we just need an easy way to talk to each other in real-time :)

I opened bug 126089 awhile ago with a proposed solution. The solution in its simplest form is an Eclipse Foundation XMPP server where all committers have accounts on (this would be part of getting your accounts provisioned when becoming a committer). If we really wanted to eat our own dog food, committers could use ECF to connect to this server (or their favorite messaging client).

What do committers think? Is this important? Do we really need yet another messaging system? If committers support this, I and the other committer representatives will do our best to make it happen.

Experiences with the Eclipse IP Process

In this week's integration build we have upgraded the org.apache.ant plugin to the Apache Ant 1.7.0 release.

To achieve this, I participated in the Eclipse IP process for non-EPL code...and I survived!

Seriously, the process was smooth, easy to understand and required only a modest time investment on my part.
I opened the request on January 31, 2007 and received approval on April 13, 2007.

Getting the approval (or denial) took much longer than I would have liked. To be honest, I was getting fairly nervous about getting a decision before the lockdown for Europa.
It is important for committers and the community for contributions to get in in a timely manner.

There will very likely be bugs that the community finds in Ant 1.7.0 and our integration of Ant within Eclipse. I have found three so far. These take time and exposure to find and fix.

As well, I believe we are a major channel for getting the new Ant releases out to the world. We had a much longer delay than in the past This is a delay in getting all those extra eyes looking at the code and finding the bugs.

Eclipse is a force in the open source community and we need to continue to have these strong indirect influences. Every delay in bundling or using other open source offerings potentially reduces this influence.

Parts of the IP process that we propose could be improved:

• indication of target date: similar to Eclipse bugs, an IPZilla request should be assigned a target and the target needs to be more refined than "Europa" or whatever the current release is. It made it difficult for me as a committer to plan my work not knowing when the approval would be coming. Predictability is important for any process.

• do the code review and board approval in parallel: it took an extra 19 days for the approval while timing out on the board approval. From my understanding this change is already in the works.

• more people to handle the load: we are serious about our IP process and we need to ensure that we have the people to deal with the work load. New IPZilla requests are just going to keep coming in and likely at an increased rate as the Eclipse ecosystem continues to grow.
  

I will be interested to see the next round when Ant 1.7.1 is released: how we evolve the IP process and the differences when a previous version of a contribution has already been approved.

We are very interested in other committers experiences: what worked well, what could go more smoothly.
Please comment so we all can work together to make this part of Eclipse even better.

Bugzilla and Flags

Howdy committers, we just wanted to make you aware of some upcoming changes to bugzilla that the Foundation (and a personal agenda of mine) has been working hard at (thanks Denis).

They are detailed in the following two bugs:

• Bug 177815
• Bug 178109

In the simplest words, flags have been added to each bug to aid searching. The flags are:

• reviewed: request a code review/flag as reviewed
• pmc_approval: request PMC/project lead approval/flag as reviewed
• documentation: flag to indicate documentation has been updated.

Also, flags have been added to patches so committers have the option to +/- a patch indicating to the patch contributor that he/she should redo the patch (see picture below).



If people have thoughts, we encourage committers to comment on the bug report or discuss it on the newsgroups.

Should Bjorn and/or Ward attend board meetings?

Probably many folks are just like me and have found Bjorn and Ward to be of invaluable service to the committer community. When I have questions about processes or infrastructure, these are the guys I go to for answers. Their latest work on a new portal is just one fine example; of course they had some help too from people like Karl Matthias and Sharon Corbett. I've often wondered how some of the councils could function without Bjorn's no-nonsense attitude, organizational skills, and personal dedication. Of course I've gotten mad at him before too, and anyone who knows me well knows that I may seem like a nice friendly guy, but when I get mad, it's not a pretty scene. But let's not go there! I'm learning not to do that in public. The point is, at that time I was taken aback by his extremely constructive reaction to my harsh criticism; that really made me respect him a great deal. Bjorn's a very good listener.

So to get to the point, I think it would provide significant value to the committer community if Bjorn and/or Ward could attend Eclipse Board meetings as observers. This would help provide continuity over the years and would help both these guys to understand more about what's going on and hence be even better helpers for our community.

I'm very curious how other folks feel about this?

Howdy Committers!

Hello Eclipse Committers (and community!), this is the inaugural post on the new committer representative blog. There are five newly elected committer representatives this year:

• Chris Aniszczyk
• Darin Swanson
• Ed Merks
• Jeff McAffer
• Konstantin Komissarchik

To start things off this term with the theme of open communication, the committer representatives have decided to do two things:

• Create a blog to keep committers aware of our activities this year.
  
• Create a newsgroup to facilitate discussion amongst committers and committer representatives. This newsgroup is meant for committers only and is open to the public for the purpose of transparency. The committer representatives plan to use this newsgroup as a way to work with committers to see what they desire or how they feel about a particular issue. A good example of an issue would be what to do with committer status? Should there be fine guidelines of when a committer would lose commit rights due to inactivity? Should there be different levels of so called committership? This is just an idea but we encourage committers to post their concerns regarding various issues.
  

In the end, we look forward to working with the committers this year in an open and transparent way. We're all ears ;)

What the heck is a committer rep anyway?

In a comment to Chris' initial committer rep post Eugene asked:

can you please explain what committer representatives can actually do and what kind of activities should we expect from you all?

It's a great question and I'll take a bit of space here to say what I think the committer reps can/should do.

First and foremost we are full and regular members of the board of directors of the Eclipse Foundation, a not-for-profit yada yada, etc, etc entity. We happen to have been elected to that position but that is neither here nor there. As members of the board we have to look out for the best interests of the Foundation. So no matter what committer motivated axes we might have to grind or business models might be funding the work at Eclipse, when working on Board matters, all members must have the success of the Foundation front and center.

Now different people have different ideas of success. That's actually what makes working on the board interesting IMHO. There are some really interesting people and discussions at the board meetings. In general, the committer reps have naturally tended to focus on things that improve the lives of committers as a way of enhancing the Foundation. Good software drives interest in membership and use which in turn drives success/security of the Foundation. Makes sense. Concretely in the past year that I have been on the board the committer elected reps have worked hard on such things as:

• IP policy changes to create a fast-track process for incubating projects
  
• Improvements in infrastructure and uptime
• The latest rev of the development process in particular the creation of the mentor role and the potential to rejuvenate the Architecture Council

I just picked a random three that sprung to mind. Committer elected reps are free to join the various committees (e.g., finance, IP, ...) that focus on particular areas as they see the need and desire.

So what should you expect from the committer representatives? More of the same I should think. Actually, last year was particularly fruitful at the Foundation level for committers IMHO. The problem is that we failed to communicate effectively what we were doing. This blog is a tangible attempt to address that failing and you should expect to see more information flowing out to you.

It must be said that the communication issue is complicated by the fact that board discussions are confidential until the board decides to publish minutes, results, policies, ... Board members, elected or otherwise, need to take care in communicating board discussions. It comes back to the role of board members -- to act in the best interest of the Foundation. Going off and blogging that we are considering merging with NetBeans would be counter productive. Well that was a joke but you get the point.

Turning the table around a bit, it would be good for us to hear from the committer community at large what you think we can/should do. Some information flow back to the board. Take the workareas mentioned above as template or examples of the kinds of things that board members can work to accomplish. We can't get a particular IPzilla CQ expedited but we can promote ways of streamlining the IP process. We can't go to project X and demand better quality but we can help put in place a mentorship program that would help X be more successful.

The committer elected board representatives are one of several windows the board has onto the committer community and vice versa. We should seek to be as transparent as is legally possible and act as a lens in focusing committer issues into items on which the board can take action.