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