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