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.
Monday, April 30, 2007
Wednesday, April 18, 2007
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:
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.
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.
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.
Friday, April 13, 2007
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:
In the simplest words, flags have been added to each bug to aid searching. The flags are:
If people have thoughts, we encourage committers to comment on the bug report or discuss it on the newsgroups.
They are detailed in the following two bugs:
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.
If people have thoughts, we encourage committers to comment on the bug report or discuss it on the newsgroups.
Subscribe to:
Posts (Atom)