Re: [cross-project-issues-dev] Performance, 3.8 versus 4.2

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

----- Original Message -----
> From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
> Sent: Thursday, September 6, 2012 1:18:26 PM
> Subject: 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.

Well, it's contributors call isn't it ? Current contributors think they can no longer support 3.x and they move on 4.x.
If there were more contributors caring about 3.x it wouldn't have been deprecated. That's how I see things. The problem is not that current contributors deprecated 3.x - the problem is that there are too few contributors.

> 
> > 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.

It's not artificial need. Platform loses contributors daily and moving to 4.x just shows the problem earlier instead of when it's already too late, which is good think in my eyes.

> 
> > 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.

Calls will always be there, the problem is that there aren't enough people to pick up the phone on the contributor's side.

Alexander Kurtakov
Red Hat Eclipse team

> 
> - 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
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>