|
Hi,
thanks Dani!
@John: Please let me know if I can help you with anything. Could
you kindly comment on the time plan, especially regarding to Mars
and EPP (see below).
@Lars: The bundle org.eclipse.e4.tools.emf.editor3x depends on the
bridge, so until we change that, we need to include it. (we should
discuss this at [2])
Best regards
Jonas
Am 21.11.2014 08:52, schrieb Daniel Megert:
We discussed this in
the PMC and gave the
go. John will start the review process.
Dani
From:
Lars Vogel
<lars.vogel@xxxxxxxxx>
To:
E4 Project developer
mailing list <e4-dev@xxxxxxxxxxx>
Cc:
John Arthorne
<john_arthorne@xxxxxxxxxx>,
Daniel Megert/Zurich/IBM@IBMCH
Date:
21.11.2014 00:57
Subject:
Re: [e4-dev]
Moving e4 tools to a new project?
Hi Jonas,
thanks for the follow up, I think the PMC needs to
act
on this.
I think we only want to move the e4 tools without
the
bridge. I'm also planning to try to contribute our Eclipse 4
project wizard
to PDE over the next couple of weeks, so this might also not be
necessary
to move. But we can still move it and delete it in case it
becomes obsolete.
Best regards, Lars
P.S. I personally still think for the e4 tools the
target
PDE would be the better home, but I go with any final decision
the PMC
makes.
2014-11-18 13:12 GMT+01:00 Jonas Helming <jonas.helming@xxxxxxxxxxxxxx>:
Hi Lars, Hi John,
is there anything holding this back? I think all active e4
committers agreed
to the move in August.
As I stated before, IMHO it would be a really important step to
bring the
e4 tools in a graduated state, in the SimRel AND on-board of an
EPP (RCP
Development). Now that we have the decision how to achieve this,
it would
be frustrating, if we loose another release, i.e. year here.
@John: Do you consider the e4 tools after the move to the
platform to be
a new contribution we have to announce separately? I am asking,
because
the deadline (M4 December 12th) for this is approaching. If not,
when would
be the deadline for you until the tools should be moved to make
it into
Mars (SimRel AND EPP).
@Both: Please let me know, if you need any help to proceed with
this. If
have created a BR [1] to track all open tasks. Another open
decision would
be this [2]
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=452061
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742
Best regards
Jonas
December 12th
Hi,
The PMC (John Arthrone did the write up)
recommended to
move the e4 tools to a separate Git repo in platform.ui (see
below). Basically
moving /gitroot/e4/org.eclipse.e4.tools.git to something like
/gitroot/platform/eclipse.platform.ui.tools.git,
maintaining it as a separate repository. e4
tools committer would not be automatically nominated as
committers, but
John indicated that in the past in a
similar sitution
anyone has had a non-trivial number of commits in the past year
was immediately
nominated.
How is the feeling of the e4 tools
developer
about this? Shall we proceed and suggest this transition?
Best regards, Lars
Extract from: https://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg02196.html
--------------------
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.
--------------------------------
2014-08-27 20:35 GMT+02:00 Wim Jongman <wim.jongman@xxxxxxxxx>:
I'm also in. Great initiative.
Cheers,
Wim
On Wed, Aug 27, 2014 at 5:39 PM, Lars Vogel <lars.vogel@xxxxxxxxx>
wrote:
PMC (in person John Arthrone) suggested a
conference call
to discussion options. I post the details once they are set.
2014-08-27 12:26 GMT+02:00 Lars Vogel <lars.vogel@xxxxxxxxx>:
Sounds like we all happily agree so far. I send an
email
to the PMC mailing list asking for approval for this change.
Best regards, Lars
2014-08-27 11:35 GMT+02:00 Olivier Prouvost <olivier.prouvost@xxxxxxxxxxx>:
Hi,
For me it is +10 ! This is a main step for the E4
success.
Tell me if I can help.
Olivier
Le 26 août 2014 à 21:42, Lars Vogel <lars.vogel@xxxxxxxxx>
a écrit :
Hi,
I think the main issue people have
with the
e4 tools is that they cannot install from directly from the
update site
of the Eclipse release. I asked in the
cross mailing
list how the e4 tools can be part of the Mars update site.
Wayne explained that we would have to move the e4
tools
to a new project. Here is his explanation how to do it:
----------------------------
To move the code out of the project,
you
need to do a restructuring review. Restructuring reviews are
relatively
simple affairs that require you describe (as concisely as
possible) what
needs to to change and why.
To restructure by moving, you need a project to move the code
into.
This could be an existing project (e.g. PDT), or one that we
create. If
a new project is required, then we need to do a proposal
followed by a
creation review. We can combine the creation review with the
restructuring
review.
There's more here:
https://wiki.eclipse.org/Development_Resources/HOWTO/Restructuring_Reviews
HTH,
Wayne
------------------
If the active e4 committers and our
users
agree, I personally think we should go ahead and create
this structuring
review.
How do people think about this?
Should
we go ahead with this restructuring review?
Best regards, Lars
P.S. I would be interesting to
work on the restructuring review.
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
|
