> 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[1]. This feeds into a nice tree view of bugs remaining for platform compatibility issues [2] as well as a view of work that has been accomplished already [3]. 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. Thanks [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=330957 [2] https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=330957&hide_resolved=1 [3] https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=330957&hide_resolved=0 From: Mike Wilson <[email protected]> To: [email protected], [email protected], 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: [email protected] 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: 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. McQ. -_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
