> It has indeed been predictable and we have even been warned > about it from the provider of the platform themselves. I > distinctively remember a message from McQ warning us all > about the various staffing issues he had, and that he had > to make drastic choices.
I remember that as well and I also remember being astonished that the plan to aggressively deprecate 3.x stream proceeded regardless. > Was Juno a good point in time to introducing such a change? > I say YES. Why? Because as the current situation shows us, > ppl don't try things until they are forced to do so and that > should we have chosen to wait until Kepler then the same > discussion would have happen but in September 2013. And > don't try the argument that you would have tried it. After > all eclipse 4.1 was released in July 2011. Sure, forcing the new platform out before it is ready is a good way to get more testing, but it accomplishes that goal at a tremendous expense to Eclipse reputation. A better approach would have been to make both 3.8 and 4.2 packages available. Users would have still tried 4.2 as everyone likes to play with the newest technology at some point. The difference is that there would have been a fallback. The current answer of "go back to Indigo or build your own 3.8 package" is terrible. > But more importantly than all this is the meta conclusion > that the era of being able to take the platform for granted > is over and that we are all going to have to pay more > attention to it, roll up our sleeves and contribute. The trouble with that line of thought is that there is contribution when there is a need. You cannot force contribution and eloquent arguments for why contribution is in everyone's best interest aren't going to work either. There hasn't been broader contribution to the platform because for most regular IDE usage, 3.x platform is viewed to be good enough and companies naturally choose to invest in other eclipse.org projects where they can add visible value. Creating an artificial need for contribution to 4.x by aggressively deprecating 3.x without demonstrating clear and obvious value to the IDE community is not going to end well. > Also remember, the Eclipse platform team shipped both > Eclipse 3.8 and 4.2 so we could transition more easily. > However, there will not be an Eclipse 3.9, so if the 4.x > platform is not useable for your needs, now would be the > time to step up with some resources. Or... We could begin to accept that 3.x is good enough and since sufficient value hasn't been demonstrated for the 4.x stream to the IDE community, it is going to take much longer than anticipated to stabilize it. Absence of 3.9 isn't going to affect that equation. Get ready for calls to include 3.8.x in Kepler. - Konstantin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pascal Rapicault Sent: Wednesday, September 05, 2012 10:06 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Performance, 3.8 versus 4.2 >> I don?t begrudge 4.x its growing pains. It is a complex technological shift with a lot of promise. What I find most troubling is the decision process that led to the use of 4.2 for Juno distros. When the decision was made, it was plainly evident that 4.2 wasn?t going to match 3.8 on any of the quality metrics. IDE users might have been ok with quality drop if 4.2 delivered compelling new functionality that you couldn?t get in 3.8, yet there is no tangible functional delta. The value of 4.x platform is for RCP developers and to certain limited extent for IDE plugin developers. Certainly not for IDE users. The refreshed look-n-feel has been touted as a big end user feature of 4.2, but the new look-n-feel itself has numerous issues that leave it looking like an unfinished project. >> >> >> Sadly, the user reaction that we?ve been seeing over the last several months has been entirely predictable. So the next question is what have we done to avoid this? To me this is a failure of the eclipse community, at least the committer / release train community. It has indeed been predictable and we have even been warned about it from the provider of the platform themselves. I distinctively remember a message from McQ warning us all about the various staffing issues he had, and that he had to make drastic choices. From that, what have we done? Did we pull up resources to help? Did we even test? After all, if it sucks today, it must have been even worst back then in March. Obviously we have not done our due diligence, at least I know I did not. Was Juno a good point in time to introducing such a change? I say YES. Why? Because as the current situation shows us, ppl don't try things until they are forced to do so and that should we have chosen to wait until Kepler then the same discussion would have happen but in September 2013. And don't try the argument that you would have tried it. After all eclipse 4.1 was released in July 2011. But more importantly than all this is the meta conclusion that the era of being able to take the platform for granted is over and that we are all going to have to pay more attention to it, roll up our sleeves and contribute. Pascal _______________________________________________ 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
