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 <[email protected]> > To: E4 Project developer mailing list <[email protected]> > Cc: John Arthorne <[email protected]>, 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 > <[email protected]_ <mailto:[email protected]>>: > 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 <[email protected]_ > <mailto:[email protected]>>: > I'm also in. Great initiative. > > Cheers, > > Wim > > > On Wed, Aug 27, 2014 at 5:39 PM, Lars Vogel <[email protected]_ > <mailto:[email protected]>> 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 <[email protected]_ > <mailto:[email protected]>>: > 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 > <[email protected]_ <mailto:[email protected]>>: > > > Hi, > > For me it is +10 ! This is a main step for the E4 success. > > Tell me if I can help. > > Olivier > > > > > _Olivier Prouvost_ > <mailto:[email protected]?subject=Demande%20de%20renseignements> > > > _Formation et Expertise Eclipse_ <http://www.opcoach.com/> > > *Mobile : **_+33 (0)6 28 07 65 64_* > <tel:%2B33%20%280%296%2028%2007%2065%2064> > > > > > Le 26 août 2014 à 21:42, Lars Vogel <[email protected]_ > <mailto:[email protected]>> 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_ > [email protected]_ <mailto:[email protected]> > 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_ > [email protected]_ <mailto:[email protected]> > 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_ > [email protected]_ <mailto:[email protected]> > 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_ > [email protected]_ <mailto:[email protected]> > 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 > [email protected]_ <mailto:[email protected]> > 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_ > [email protected]_ <mailto:[email protected]> > 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
