Option 3 sounds good to me. Remember that the EDP requires that we
do a restructuring review (a few sentences describing the change is
all that is required) and the IP Policy requires that we do an IP
Log review/approval of e4.
FWIW, if the code is already in its own Git repository, we can just
move the Git repository.
Wayne
On 08/09/14 02:14 PM, John Arthorne
wrote:
Hi Lars,
We had a discussion about this in
our
last PMC call. We talked about the following options:
1) Migrate tools into a new
project
2) Migrate tools into PDE
3) Migrate tools into Platform UI
Option 1) is always a
possibility. There
is some added overhead with each new project, such as committer
elections
and various other bits of Eclipse process. In general if there
is an existing
project that is a good fit I would recommend that over the work
of creating
an indefinitely maintaining a new project.
Option 2) makes sense on a
conceptual
level because PDE is the home of all tooling specific to the
Eclipse platform
runtime. However there is absolutely no connection between these
tools
and the existing PDE code base, and no overlap between
committers. So it
"fits the category" but otherwise has no common ground with the
contents of that project. Also, once modularity comes to the
Java language,
we will likely see PDE align more closely with JDT, and the e4
tooling
doesn't fit with that.
Option 3) is compelling because
there
is a strong overlap between current committers on both tools and
runtime,
and of course close relationship between the tooling and runtime
code -
when one has significant changes the other likely needs to react
to it.
After some discussion, all members of the PMC are in favor of
this option
and this is what we recommend. This would be implemented by
creating a
new Git repository under Platform UI project to host the tools,
and then
elect all active contributors on the graduating tooling into
Platform UI.
It would initially be a separate feature that is available in
the project
repository that is installed separately (like Eclipse Releng
Tools, for
example). This would immediately accomplish the goal of making
it easy
for end users to install into Eclipse Mars and beyond. In the
future it
could be added to EPP packages where that makes sense (such as
the RCP
development package).
So Option 3) is the current PMC
recommendation,
but if the e4 tools contributors want to take it in a different
direction,
such as a new project, we are happy to talk about it. What do
you think?
John
From:
Lars Vogel
<lars.vogel@xxxxxxxxx>
To:
eclipse-pmc@xxxxxxxxxxx,
Date:
08/27/2014 11:38 AM
Subject:
Re: [eclipse-pmc]
Restructuring review for the "e4 tools" Git project migrating
to its own project
Sent by:
eclipse-pmc-bounces@xxxxxxxxxxx
Hi John,
thanks. Call sounds like a good idea.
Best regards, Lars
2014-08-27 14:57 GMT+02:00 John Arthorne <John_Arthorne@xxxxxxxxxx>:
We had to cancel our PMC call
today
because several of us were out or unavailable, so we'll need to
talk about
this next week. I have to say I always thought of PDE as the
eventual home
for all those tools. Note that being under the same project does
not necessarily
mean they have to be included in the same feature as the basic
plugin tooling.
It could be built as one or more separately installable features
that live
under the same project. They could even live in a separate Git
repository
from the other PDE code. The only tangible difference with a new
project
is that it has a distinct committer group. But in the long term
I'm not
sure there will be a large enough committer base for that to be
needed.
Would it be worth setting up a call to talk about the different
options
here?
John
From: Lars
Vogel <lars.vogel@xxxxxxxxx>
To: eclipse-pmc@xxxxxxxxxxx,
Date: 08/27/2014
06:36 AM
Subject: [eclipse-pmc]
Restructuring
review for the "e4 tools" Git project migrating
to its own project
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
Hi,
e4 tools provide the tools to create and work with Eclipse 4
based applications,
IDE's as well as RCP applications.
Parts of the tools are planned to get integrated into PDE, i.e.
the e4
project wizard. But others, like the application model editor
and the "spies"
are currently not planned to be integrated to PDE as they (in
parts) depend
on extensions of the EMF framework, like the EMF undo / redo
support.
The e4 tools would like to get included into the "official" Mars
release. Our users complain that they have to seek a different
update site
to get the tools integrated.
As we are currently part of the e4 incubator project Wayne
advised that
we need to do a restructuring review migrating our e4 tools code
to a new
project. https://wiki.eclipse.org/Development_Resources/HOWTO/Restructuring_Reviews
advises that we seek PMC approval for that early in the process.
Can the PMC advice if it OK with such a restructuring review? As
new project
name I think "e4 tools" would be good.
Best regards, Lars
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
 |
