[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] Contributing the Eclipse SDK R4.2 to the Juno simultaneous release
- From: David M Williams <david_williams@xxxxxxxxxx>
- Date: Thu, 26 Jan 2012 11:10:03 -0500
- Delivered-to: email@example.com
> There is still calendar time for you to have a positive impact on
> the Juno release if you wish to participate.
I know you all tire of me saying "test early, test often" ... but ...
One important way to contribute to Juno, is to do plenty of testing with
4.2. I have heard a few committers-and-consumers-who-should-know-better
confess "oh, I have just now started using 4.2 and noticed ...
" [ sigh :/ ]
In a way, we -- the consumers of "the platform" -- are provided an ideal
situation of being able to test both 3.8 and 4.2 to compare results, and
find compatibility issues. I think in many open source projects (and some
past, long ago Eclipse releases) the approach would be more "we are making
the change ... with no transition strategy ... hang on tight". So, let's
take advantage of the opportunity of having both and do some good quality
testing, with good reports, making sure to determine if a bug is a true
compatibility issue, a regression, or simply a typical bug ... all are
important to know about, but this plea concerns the compatibility issues.
If you open compatibility bugs about 4.2 Platform based projects (including
appearance or performance differences between 4.2 and 3.8), please mark
them as "blocking" the umbrella bug 330957. This feeds into a nice tree
view of bugs remaining for platform compatibility issues  as well as a
view of work that has been accomplished already . You will notice the
tree view is organized by major projects typically on the release train. If
you would like -- if your project is not on there, and if you think it
helps organize the list -- feel free to add your own project or category
(using a new umbrella bug that blocks bug 330957 and then mark your
compatibility bugs as blocking your own umbrella bug).
Having a good quality bug report is the most important thing (they can be
organized later, and as we go), but having the compatibility issues well
documented and organized will help the platform team know where the most
important areas are, to focus on, before the Juno release as well as give
us all a central place to look for compatibility issues.
From: Mike Wilson <Mike_Wilson@xxxxxxxxxx>
To: eclipse-dev@xxxxxxxxxxx, cross-project-issues-dev@xxxxxxxxxxx,
Date: 01/25/2012 04:26 PM
Subject: [cross-project-issues-dev] Contributing the Eclipse SDK R4.2 to
the Juno simultaneous release
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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
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:
1. 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.]
2. 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.
3. 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.
cross-project-issues-dev mailing list