OK, I’m awake and have a coffee on the go. As the PMC rep to the planning council I’ll be +1’ing the request and passing it along to the planning council who are ultimately the ones who decide whether there’s a respin.
But before they do that, I want to make a couple of points and ask for your help.
First, we’re having this discussion because we found this issue now and not next week. In a sense, we’re lucky we’re in a position to fix this before the release. Even if it pushes back the release by a week, which it will.
We need a plan to mitigate these issues no matter when they happen and we should have the technology to do it. Projects need the ability to release maintenance releases any time and have those releases picked up with an Automatic Check for Updates in the
EPP packages. We’ve talked about this in the Architecture Council and need your help to make sure this works and that the projects and packages are structured properly to make sure it works.
BTW, I’m glad the community on cross-projects has spoken on this. It’s great input to the planning council who ultimately makes the decision. And that decision hasn’t been made yet, so there’s still hope :). We’re a bunch of engineers making product decisions,
but we’ll try our best.
Doug
Fyi, in a separate email to the Tools PMC mailing list, I have requested the Tools PMC to approve a re-spin of Mars 1 RC4.
Etienne
Hi Etienne,
Since then, Buildship has been downloaded about 10’000 times but only 2 people reported a problem
Well, I think this is not a strong indication for two reasons:
- Eclipse-IDE-wide we see more than half a million submitted (automated) error reports in the last quarter - which boil down to twenty-thousand distinct problematic locations in source code. Most of them are NullPointerExceptions. How many of them
have been reported before?
- I also doubt that many users relate the disappearance of the dialog with Buildship, thus, rather blame Eclipse than Buildship. It’s a subtile but annoying bug.
Besides that:
* I weight the cost of a respin much lower than the annoyance users might experience
* I now understand that this issue occurs for Gradle users only (thanks for explaining) - but for all of them. As of today 10.000 users got affected by it. From October to February (Mars.1) 10.000 * x users will get affected by it again. This
is a fair amount of users IMHO.
* I assume Buildship would prefer to ship the fixed version (maybe I’m wrong).
So far the discussion has been lead by a handful people - which likely is not representative for all opinions.
If I summarize correctly: David is fine with keeping it "as is“, Mikael want’s a respin. I second Mikaels position.
Maybe others have no strong feelings or don’t care.
It’s not on me to push a decision. But I’ve a clear preference - pro our users and pro Buildship.
Marcel
Hi Marcel
Only Buildship users that have launched at least one Gradle task from the Tasks View may be affected. And, even then, only two users have reported a problem with the workspace prompt so far.
Please note that we introduced the call to bundle.start() on June 6th. Since then, Buildship has been downloaded about 10’000 times, but only 2 people reported a problem with the workspace prompt (if that serves as any kind of indication).
Etienne
I commented on the linked bug and currently strongly disagree with David’s opinion.
Short:
If every Eclipse user using the Java, Java EE, or RCP/RAP EPP Package is affected by this, then its no doubt a blocker.
Then, I vote for a rebuild (and if necessary for postponing the release if necessary - just to make clear how strong I feel about it).
If not every Java, Java EE, or RCP/RAP EPP Package user is affected by it, I’d like to understand when this issue occurs - and when it doesn’t.
Follow-ups in Bugzilla.
Marcel
My favourite NetBeans troll couldn't miss this opportunity
https://twitter.com/ehsavoie/status/646583406176960512
Tha and my regular chats with various IDE users (I spend a few hours monthly trying to convince IntelliJ and NetBeans users that Eclipse IDE isn't that bad) make me feel that this issue is "reputation busting embarrassing". At least, I don't know how I could
keep on evangelizing about Eclipse IDE if our community is OK to ship a major bug in a high visible project to its users.
The bar of quality expectation has raised, IntelliJ and NetBeans are doing a great job, shipping applications that seem mostly bug-free. If we want Eclipse IDE to stay relevant we cannot ship applications with a critical bug.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Codetrails GmbH
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Codetrails GmbH
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|