Nailed it.
Wayne
On 15/09/14 02:53 PM, John Arthorne
wrote:
I interpreted this as
physically moving
the Git repository from /gitroot/e4/org.eclipse.e4.tools.git to
something
like /gitroot/platform/eclipse.platform.ui.tools.git,
maintaining it as
a separate repository.
John
From:
Daniel Megert
<daniel_megert@xxxxxxxxxx>
To:
eclipse-pmc@xxxxxxxxxxx,
Date:
09/15/2014 05:17 AM
Subject:
Re: [eclipse-pmc]
Restructuring review for the "e4 tools" Git project migrating
to its own project
Sent by:
eclipse-pmc-bounces@xxxxxxxxxxx
> FWIW,
if the
code is already in its own Git repository, we can just move the
Git repository.
Do you mean move into the 'eclipse.platform.ui.git' repository?
When we
discussed this in the PMC meeting, we were in favor of having a
separate
repository for the tools but owned by the 'eclipse.platform.ui'
project/group
(similar to e.g. 'platform.ua.git').
Dani
From: Wayne
Beaton <wayne@xxxxxxxxxxx>
To: eclipse-pmc@xxxxxxxxxxx
Date: 08.09.2014
21:14
Subject: Re:
[eclipse-pmc] Restructuring review for the "e4 tools" Git
project
migrating to its own project
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
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
[attachment
"ECE Friends 480x60.png" deleted by Daniel Megert/Zurich/IBM]
_______________________________________________
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

|