At the last Eclipse Architecture Council meeting, I said that we, the
Eclipse Project, thought that our ability to deliver the Eclipse SDK R4.2
as part of Juno was at risk. I am happy to say that we have been able to
re-align our development effort, and now expect to deliver Eclipse SDK R4.2
as part of Juno. I wanted to talk briefly about how we ended up in this
situation, and then cover the highlights of what we are doing to mitigate
the risk.
Almost all of the new work in 4.2 is focused around the Platform UI team.
When the planning for Juno started, there were 7+ people working (for me)
full time on that team. Since then, a number of individuals have left the
team to pursue other opportunities. Each time this happened, we looked at
what needed to be done, how many people were left, whether we could pull in
someone from somewhere else to help, and in the end managed to convince
ourselves that a successful delivery was possible.
Last week, two more people told me that they had decided to leave. This
left us with just 3 developers working on Platform UI, and that's when I
brought the situation up with the EAC; three people, alone, are not enough
to deliver a 4.2 of acceptable quality.
Since then, I have worked with the remaining UI team members and the
Eclipse PMC to come up with a plan which we believe will allow us to
succeed. The highlights of this plan are:
We looked at the other component teams to see whether there was work
that could be delayed to free up resources to join the UI team. Because
we believe it is critical that 4.2 be part of Juno (see below), this
trade off made sense, even though it left some other teams with
effectively no active developers. [Even so, we could only add two new
people this way, and they will take time to ramp up.]
We took many of the "peripheral" tasks that people from the UI team were
working on (e.g. builds, legal/IP, internal company interactions,...)
and moved these to others elsewhere on the team.
We made some hard decisions about where to focus our resources. For
example, we decided that providing API for the new capabilities of 4.x
would have to happen post-4.2. Working on solid backwards compatibility
and performance need to be our first priorities.
Some might argue that it would be better to simply release 3.8 into Juno
and move ahead with the 4.x stream in a follow on release. Honestly, I
believe this would be catastrophic for our community. The Juno simultaneous
release is going to be the basis for both the first Eclipse Long Term
Support and first Very Long Term Support offerings. Given that, plus the
overall maturity of Eclipse and the requirements of many of the large
organizations that are participating, I see the Juno release as being
extremely important. If we are unable to deliver 4.2 in Juno it would mean
that a huge segment of the community would not be able to take advantage of
the new features it provides, but more importantly they would be building
on a code base that we know needed to be replaced -- that was, after all,
the impetus for the 4.x work in the first place. It would literally mean
that it would no longer be possible for the Platform (that we all build on)
to adapt to the changing needs of modern, desktop applications. And this,
more than anything I can think of, would jeopardize the future of Eclipse
on the desktop.
In the end, what's clear to me out of all of this is that the Eclipse
Platform UI team, and indeed the Eclipse Project as a whole, *needs* more
non-IBM committers now. And by that I mean more, *active*, "working on the
SDK for the good of the community in general" people. All those arguments
about lack of diversity on the Eclipse Project are coming home to roost: It
is clear now, that the remaining IBM Eclipse committers are too few to
support the entire SDK. It is a virtual certainty that we will see more
situations like we did recently with the Platform User Assistance team;
that is, we will get to the point where there are no longer *any* active
committers left on some areas of the SDK. I tell you truthfully, I am
committing all of the people that I can to working on the SDK, but if we
(the Eclipse community) care about Eclipse having a future on the desktop,
other resources need to be found. There is still calendar time for you to
have a positive impact on the Juno release if you wish to participate.
McQ.
-
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
