Bugzilla – Full Text Bug Listing
| Summary: | [restructure] eclipse.e4 Move e4 tools into Eclipse Platform UI | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | John Arthorne <john.arthorne> | ||||
| Component: | Proposals and Reviews | Assignee: | Eclipse Management Organization <emo> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, jhelming, john.arthorne, Lars.Vogel, olivier.prouvost, sptaszkiewicz, wayne.beaton, wim.jongman | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| URL: | https://projects.eclipse.org/projects/eclipse.e4/reviews/move-e4-tools-eclipse-platform-ui | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 452061, 455125, 458555, 459799, 462797 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
John Arthorne
I have submitted the e4 IP log in preparation for the review. I've created a review record based on what you've provided here. I arbitrarily picked Dec. 17 as the review date. If we can get the IP Log approval and PMC approval of the review documentation ready in time, we can wrap this up on Dec. 3 You should be able to edit that review record. I'm generally content with what's already there. The only addition that I might recommend is a list of the specific functionality that will be moved. Note that any committers that might need to move must be elected via the regular process. https://projects.eclipse.org/projects/eclipse.e4/reviews/move-e4-tools-eclipse-platform-ui I've forwarded the IP Log to the IP Team for their review. As discussed here https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742 we only want to move the following bundles and features: org.eclipse.e4.tools.compat org.eclipse.e4.tools.emf.editor3x org.eclipse.e4.tools.emf.liveeditor org.eclipse.e4.tools.emf.ui org.eclipse.e4.tools.jdt.templates org.eclipse.e4.tools.services org.eclipse.e4.tools and the feature which contains them: org.eclipse.e4.core.tools.feature (In reply to Jonas Helming from comment #4) > As discussed here https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742 > we only want to move the following bundles and features: Do these plug-ins/features share a Git repository with anything else? If yes, you can start the process of separating the repos whenever you'd like. I assume that just moving the existing repository is the desired approach to implementing this change. OK, so what you are saying is that we should separate the bundle we want to move to a new repo in the existing project before we do the move? (In reply to Jonas Helming from comment #6) > OK, so what you are saying is that we should separate the bundle we want to > move to a new repo in the existing project before we do the move? I'm more suggesting that you can. If it's easier to wait, you can do that instead. Created attachment 248882 [details]
Approved IP Log
In anticipation of a positive response from the PMC, I've scheduled the review to conclude on Dec. 17. (In reply to comment #9) > In anticipation of a positive response from the PMC, I've scheduled the review > to conclude on Dec. 17. PMC approval: https://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg02233.html @:Wayne: Now you have confused me even more! :-) What should we wait for? To make it clear: The repository contains the components, we want to move, but also components, which should stay in the existing e4 project. We therefore move all bundle to be transfered in a separate repository NOW AND BEFORE THE TRANSFER, right? Please do not confused me even more! :-) (In reply to Jonas Helming from comment #11) > @:Wayne: Now you have confused me even more! :-) Good. It's working. :-) > What should we wait for? No need to wait. > To make it clear: The repository contains the components, we want to move, > but also components, which should stay in the existing e4 project. We > therefore move all bundle to be transfered in a separate repository NOW AND > BEFORE THE TRANSFER, right? Sometime after the review is successful, a Git repository containing only those components that are included in this review will be moved to the Platform UI project. At some point, you'll need to separate out the components that are moving from the e4 Git repository. You can decide when you do the actual work of separating out those components into a separate Git repository. > Please do not confused me even more! :-) Where's the fun in that? More seriously, I hope that I've met this goal. If not, I'll take another crack at it. Or, maybe I should just stop trying. I'm pretty sure that you already know what needs to be done. Would it do any harm to copy the repo as it is and to remove the bundles in the copy then? As all code comes from an existing Eclipse project, the ip review is probably not affected anyways. Anyways, I will do the split. @Wayne: could we get a new repo in the e4 project called "org.eclipse.e4.tools.core"? Or shall I create a new BR for this? (In reply to Jonas Helming from comment #13) > Would it do any harm to copy the repo as it is and to remove the bundles in > the copy then? As all code comes from an existing Eclipse project, the ip > review is probably not affected anyways. That would be weird. Also, it would screw up the IP Log since it reviews all commits. (In reply to Jonas Helming from comment #14) > Anyways, I will do the split. That would be better. > @Wayne: could we get a new repo in the e4 project called > "org.eclipse.e4.tools.core"? Or shall I create a new BR for this? Anybody with shell access can do this. If you don't have that access, ask Webmaster for help. Hi, What about the spies ? You don't plan to move the following bundles : - org.eclipse.e4.tools.context.spy - org.eclipse.e4.tools.css.spy - org.eclipse.e4.tools.event.spy - org.eclipse.e4.tools.spy while you keep the emf.liveeditor which is a spy ? Olivier, it is not "you", it is "us". The bundles to be moved have been discussed here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742 Although there was not much feedback. If you feel like reopening this decision, please do so and comment on the BR. Best regards Jonas Ok Jonas ! I missed this discussion (the title was not very explicit). It would have been cool to discuss it during ECE also but we were probably too busy... I believe we need to be moving an entire git repository. Permissions are handled at the Git repository level, so the concrete thing that will be done is chown the repository to belong to the new committer group. Also preserving commit history for the things being moved is valuable. If there are things that we don't want to move, they can be copied into a new git repository in e4, and then deleted from master in the tools repository being moved. On the other hand, it is fine to have bits and pieces that are not being shipped as mature bundles, to continue living in the same tools repository. Many of our "mature" component repositories have various tools and utilities in them that are not shipped, but live in the same repository alongside our production source code because they are developed and used by the same set of committers. (In reply to John Arthorne from comment #19) > If there are things that we don't want to move, they can be copied into a > new git repository in e4, and then deleted from master in the tools > repository being moved. My only concern is that just removing from master will leave the commits that added the removed stuff in place. The IP Log generator and our metrics gathering will include them. This is no big deal if we're talking about a small number of commits; but if, say, half of the commits are bogus, I think that it'd be better to split the repository. @John and Wayne: By "split" I mean to create a new repository containing only the bundles, we want to move. This will also clean the history of things we do not want to move. So that should work for everyone, I guess. I am currently waiting for a conclusion on https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742 and then I will do the split. While https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742 is still not yet concluded I have two more open questions: 1. Once the components are moved, are they considered to be a new simrel contribution from the platform project? Based on the current dependencies, they are probably +2. So does this has to be announced explicitly? If so, is someone from the platform project willing to announce this right now? 2. Is the move also a graduation? If so, the platform project would probably like if we complete all steps to graduate the components to be moved beforehand (versions, licenses, etc.)? (In reply to Jonas Helming from comment #22) > 1. Once the components are moved, are they considered to be a new simrel > contribution from the platform project? Based on the current dependencies, > they are probably +2. So does this has to be announced explicitly? If so, is > someone from the platform project willing to announce this right now? I'm not familiar with the announcement process, but I think we should wait with the announcement until we have successfully move. Or is their a need to announcement that now? If this is considered to be a new contribution and therefore needs to be announced, it must be announced for M4 to get into Mars (which is effectively now). If it is considered to be just another part of Platform UI, we are fine. Let us see what Wayne says... (In reply to Jonas Helming from comment #22) > While https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742 is still not yet > concluded I have two more open questions: > > 1. Once the components are moved, are they considered to be a new simrel > contribution from the platform project? Based on the current dependencies, > they are probably +2. So does this has to be announced explicitly? If so, is > someone from the platform project willing to announce this right now? Projects are the level of granularity for contribution to the simultaneous release, so they'll be +0 with the rest of the Eclipse project. > 2. Is the move also a graduation? If so, the platform project would probably > like if we complete all steps to graduate the components to be moved > beforehand (versions, licenses, etc.)? Nope. Graduation means something particular in the EDP. This is a bunch of code that is moving from an incubating project to a regular project. You can say that the code is "graduating from the incubator"; strictly/formally speaking, however, the code is moving as part of an EDP "Restructuring" review. (In reply to Jonas Helming from comment #24) > If this is considered to be a new contribution and therefore needs to be > announced, it must be announced for M4 to get into Mars (which is > effectively now). If it is considered to be just another part of Platform > UI, we are fine. Let us see what Wayne says... It's not a new contribution from the perspective of the simultaneous release. It's some additional functionality in an existing project (FWIW, it is exactly this from the perspective of your next release review). You should still announce that, thought. It's good information that may impact some downstream consumers. We really have to nail down what is moving before EOB on Wednesday. The mechanics of making it actually happen can take longer if necessary. The tools have a dependency to +1 components such as emf.edit, which cannot be easily removed, so IMHO, they cannot be contributed +0 Sorry for bringing this up again here and so late, but that seems to be a blocker for me. It has been on the table when the committers and the PMC discussed whether the tools should be moved to PDE, the platform or a new project (no criticism). Technically, I do not see an issue here. We have a separate repo, build and downloads area and we can configure a separate contribution. The question is whether this exception could be allowed. About what is goning to be moved: I am pushing on https://bugs.eclipse.org/bugs/show_bug.cgi?id=445742 and I hope we can close it until next Wednesday. I have asked the webmaster to create the new repository: https://bugs.eclipse.org/bugs/show_bug.cgi?id=455125 I'm very sorry for the delay. I declare this review successful. Please work with the webmaster to make the necessary changes. Note that if you need to move committers, you'll need to do that via committer election. If you have commits in that code that are attributed to committers who are not moving with the code, please let me know (via email to emo@eclipse.org) so that I can fix the IP Log to show them as "past committers" rather than contributors. I'll leave this bug open until the actual move is complete. I've added Bug 455125 as a blocker; are there any other bugs we should add? Added the umbrella bug for doing the actual move (In reply to Jonas Helming from comment #26) > Technically, I do not see an issue here. We have a separate repo, build and > downloads area and we can configure a separate contribution. The question is > whether this exception could be allowed. Yes it is never as black and white as the +0, +1, etc structures imply. Platform already has external dependencies on ECF, Equinox, and EMF. I think as long as those upstream and downstream are satisfied with when a component is delivered, we can make it work. I added a reminder BR for the last missing step in the process. Move was completed for 4.5. |