I do not make purchasing/consortium participation decisions on behalf of NVIDIA. I am an input to such decisions made by my superiors.
What I am writing to this list is my personal opinion.
At NVIDIA, I am working on "Nsight Eclipse Edition" - that is an Eclipse-based IDE for CUDA developers. Before NVIDIA I was working on other Eclipse-based IDEs (paid or not).
I find it ironic that it is possible to get GSoC student work on adding generics to the JFace into the main repo, while experienced developer's contribution of image viewer (I mentioned the bug number in my original letter) was rejected with prejudice.
I personally had to implement similar viewer more then once for different projects.
I am looking at this WG from a point of view "what would we get for participation" - as this is the question I need to answer if I raise this topic with my manager.
Personally, I believe there is a need for a more open collaboration place for adopters to work on what they see as a better Eclipse Platform for IDEs. Currently adopters are forced to ship their own forks - so I wonder if this project could become some
sort of unified fork that better suits the needs of IDEs.
One thing I would like to point out is that for some teams it might be easier to contribute developer time than money as those decisions are made on different levels and development teams more readily recognize the value of collaboration.
Best regards,
Eugene
Before playing this back-and-forth:
What's your position on the WG - or funding developers in general that work on, say, JDT, CDT or EMF? Are you looking at this from an investors view point or more from a developer's view point. Not sure what the role of a lead architect at nvidia is.
In any case, from your writing I get the impression that you don't see any good way to contribute to the existing platform (no critic in here). If that's true, what can we do? Will all tries to modernize the Eclipse IDE fail?
Marcel
Gunnar,
Replies inline.
So let's imagine some company is really bothered by such issues and joins this working group (note the hefty price tag of $120k/year).
The price tags are just a proposal and haven't been validated currently. But I think you are referring to the highest one which includes steering committee membership.
My understanding is that non-steering participation does not give any voting rights.
1. Are there any guarantees somebody would actually implement these enhancements? What may prevent these funds from being spent on EMF enhancements if they get more votes?
I think it will be important to make that the working group operates open and transparent. Therefore, the whole funding and wishlist including voting will be visible. That allows to make a clear judgment on what impact specific funding will make.
This means that either companies invested in CDT or EMF will not get what they joined for.
2. What would be a timeframe before implementation starts? Would there be a committed delivery schedule?
I expect this to happen as part of the work item analysis and upon assignment of such items to the implementation partner.
How will this happen? A lot of time will be spent defining the "wish list", then RFPs will be sent out, prospecting "implementation partners" will submit proposals, voting on proposals will commence, so on? Sounds like years will pass without any output.
3. How could such a general-purpose text editor avoid sharing the fate of
Bug 155323?
It's an important role of the working group steering committee to find solutions to such problems. I could imagine that if no project is willing to accept a feature such as a general purpose image viewer or text file editor, the work is brought in as a
new project and made available as part of the release train and in the downloadable packages.
I do not think these two items can happen without at least some platform changes (I am only familiar with E3 - and at least hooks will have to be put there).
Best regards,
Eugene
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
