[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Performance, 3.8 versus 4.2
|
> 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: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
