+1 for option 3. I would also suggest moving any 'non-UI e4-tools' code into a separate package for future management, as it might not be appropriate in a *.ui project.
Has anyone looked in the the dependency overlap between e4-tools and the other projects. I think this is more of an issue then 'commiter overlap'. In my experience, the dependencies usually spell out where a code-base should live. Steven Spungin TwelveTone LLC www.twelvetone.tv From: "Olivier Prouvost" <[email protected]> To: "E4 Project developer mailing list" <[email protected]> Sent: Tuesday, September 16, 2014 3:35:48 AM Subject: Re: [e4-dev] Moving e4 tools to a new project? +1 for me Olivier Prouvost Formation et Expertise Eclipse Mobile : +33 (0)6 28 07 65 64 Le 15 sept. 2014 à 22:20, Wim Jongman < [email protected] > a écrit : +1 Do Gerrit reviews count as well? On Mon, Sep 15, 2014 at 9:43 PM, Lars Vogel < [email protected] > wrote: BQ_BEGIN 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] > : BQ_BEGIN I'm also in. Great initiative. Cheers, Wim On Wed, Aug 27, 2014 at 5:39 PM, Lars Vogel < [email protected] > wrote: BQ_BEGIN 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] > : BQ_BEGIN 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] > : BQ_BEGIN Hi, For me it is +10 ! This is a main step for the E4 success. Tell me if I can help. Olivier Olivier Prouvost Formation et Expertise Eclipse Mobile : +33 (0)6 28 07 65 64 Le 26 août 2014 à 21:42, Lars Vogel < [email protected] > a écrit : BQ_BEGIN 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] 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 BQ_END BQ_END _______________________________________________ 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 BQ_END _______________________________________________ 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 BQ_END _______________________________________________ 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 BQ_END _______________________________________________ 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 BQ_END _______________________________________________ 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
