I will postulate that one of the reasons that contributors have a hard time dealing with rejection of their feature by platform is that they see similar features already in the platform. For instance, why should the platform have a text editor, but not an image viewer/editor? This problem could be mitigating by spinning off existing platform features into separate projects such that the platform is truly just the core pieces that everything else builds upon. Once this is done, it will be easier to explain to potential contributors why their contribution is outside the scope and to point at other similar stand-alone examples that they can mimic.
Another advantage of spinning off features into micro-projects is that projects have defined lifecycle in EDP. No one active left on the project? Project dies and gets archived, or perhaps another interested party shows up and EDP provides a way for them to get into the project.
Some believe that mega-projects with many committers are better than micro-projects, because mega-projects tend to have better survival odds. While this is true, mega-projects attain better survival by hiding the true active status of their components. That isn’t an improvement.
- Konstantin
For any major new feature like this, the two main concerns are typically:
1) Bloat. Some people want it, and others don't. Some are happy with an embedded browser or a different editor, some have no need for it, etc.
2) Long term maintenance. Initial contributions are one thing, but in a few years someone still has to maintain it.
Over the years I think we have found better ways to handle these issues, rather than demanding they be solved before anyone can even start coding.
For 1), it is relatively easy in the image editor case to have a separate plugin and a separately installable feature. I don't think an image editor belongs in the Platform feature such that it can't be installed/uninstalled separately. On the other hand that question is less interesting than it used to be. The Eclipse SDK is now an EPP package and can consume features from any release train project, and the decision of what to include is no longer in the hands of those stingy Eclipse PMC members :). For the other example of inserting a hook that controls what to do when no editor is found, that feels very much like a mechanism that belongs in the platform. Of course the specific behavior of what any particular implementation of that hook does is an external concern.
For 2), the more recent approach has been to not worry about this up front. Such a feature would immediately be accepted in e4 if there was no other project wanting it, and anyone interested would become a committer immediately. If the technology proved mature and stable after awhile it would migrate into another project or a project of its own. I do agree with several others who have commented here that at the Eclipse Foundation we lack a smoother/simpler organizational mechanism for small scale independent features and projects.
I think another way to deal with this fear of long term maintenance burden is to become more willing to drop functionality that is no longer maintained. If features are kept architecturally disentangled and separately installable, they could be removed from builds/releases as soon as there was no longer a committer willing to maintain them. It is getting a bit off-topic but there are some current Platform components today in this state (e.g., Ant, CVS) and we will eventually need to decide as a community how to gracefully exit from providing them if nobody wants to maintain them.
It is important to point out that the image editor is just one example that was useful for illustrative purposes here. I think the same concerns hold true with, for example, the CSS editor that currently lives in e4 and was largely implemented by platform committers. The concerns of bloat and long term maintenance apply here too, and nobody should have the impression that who wrote the code is relevant to determining the right path in these cases.
John
From: Doug Schaefer <dschaefer@xxxxxxx>
To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>,
Date: 10/21/2013 02:41 PM
Subject: Re: [ide-dev] IDE working group questions
Sent by: ide-dev-bounces@xxxxxxxxxxx
Maybe this is a case where the Eclipse IDE Project makes sense. Then we wouldn't be having this discussion and the Eclipse IDE would have it's image viewer. Mind you, we still might need changes to the Platform to enable it, but they would be in the right direction of making the Platform more pluggable.
BTW, we have a lot of functionality in the CDT that really belongs in the Platform, In Our Humble Opinion. We just found it easier (back in the dark times), to just implement it close to home. I wonder how many other projects have done the same. I'd bet we could build up an IDE project with a lot of functionality day one.
But I'd like to hear from Platform leadership team first. Does the Platform want to open up more in this direction? Or would they prefer we find a different home for these common features.
Doug.
From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
Reply-To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: Monday, 21 October, 2013 2:20 PM
To: 'Discussions about the IDE' <ide-dev@xxxxxxxxxxx>
Subject: Re: [ide-dev] IDE working group questions
Having been involved in the discussion and having made several attempts to facilitate a solution, I see the image viewer story as most illustrative of what happens when a contributor is unwilling to be flexible. Various options were offered that would have led to an image view in Eclipse IDE packages, but it was either in platform or nowhere, so in the end we have no image viewer in Eclipse IDE to date.
Projects will reject features for various reasons. We need to be ready to find alternate accommodations and contributors need to be flexible enough to work with such accommodations. We are certainly better prepared for this today than six years ago. EMO is more willing than before to accept micro-projects and improvements in common infrastructure (such as the common build system) make it a lot less costly to have a project around a single feature, if such thing is necessary.
- Konstantin
From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Monday, October 21, 2013 10:55 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] IDE working group questions
BTW, to be fair fair about the image viewer story, the rejection happened 6 years ago near the end of the dark times…
From: Eugene Ostroukhov <eostroukhov@xxxxxxxxxx>
Reply-To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: Monday, 21 October, 2013 1:39 PM
To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Subject: Re: [ide-dev] IDE working group questions
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
On Oct 21, 2013, at 9:24 AM, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:
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
Am 21.10.2013 um 17:54 schrieb Eugene Ostroukhov <eostroukhov@xxxxxxxxxx>:
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
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
