Bugzilla – Full Text Bug Listing
| Summary: | Move org.eclipse.pde-feature from eclipse.pde.git to eclipse.pde.ui.git | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Lars Vogel <Lars.Vogel> |
| Component: | UI | Assignee: | Lars Vogel <Lars.Vogel> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | curtis.windatt.public, daniel_megert, david_williams, Lars.Vogel, markus.kell.r, Vikas.Chandra |
| Version: | 4.5 | ||
| Target Milestone: | 4.6 M6 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: |
https://git.eclipse.org/r/58174 https://git.eclipse.org/r/58175 https://git.eclipse.org/r/58176 https://git.eclipse.org/r/66640 https://git.eclipse.org/r/67797 https://git.eclipse.org/c/pde/eclipse.pde.git/commit/?id=ad69cda946d859024567dfa4ae9e0e4a861c4d26 https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=31abc40457f9d1a3ee92ac4925fe2d4e81b1f659 |
||
| Whiteboard: | |||
|
Description
Lars Vogel
Curtis, what do you think? We moved the org.eclipse.pde project to pde.ui a while back. I thought there was a stated reason why we couldn't move the feature as well, but I couldn't find one in my bugzilla search. cc'ing David in case he knows of a reason. If there is nothing preventing us from doing so, yes it should be moved. (In reply to Curtis Windatt from comment #2) > If there is nothing preventing us from doing so, yes it should be moved. FYI - in platform ui we have our plug-ins together with our feature in the same repo. Are all the plugins in that feature, also in the ui repository? If so, seems like a good idea. (Or, does it "combine" plugins from multiple repositories? If it did, I couldn't see it). There might be some implications for part of the build ... I believe where we create our repository we refer to some features with "../../pde.feature" type of (not recommended) pattern? (In reply to David Williams from comment #4) > Are all the plugins in that feature, also in the ui repository? If so, seems > like a good idea. Yes > There might be some implications for part of the build ... I believe where > we create our repository we refer to some features with "../../pde.feature" > type of (not recommended) pattern? I don't know that, I'm still hoping to get an "audience" with you to ask my questions about the build. New Gerrit change created: https://git.eclipse.org/r/58174 New Gerrit change created: https://git.eclipse.org/r/58175 New Gerrit change created: https://git.eclipse.org/r/58176 David, can you point me to the information how I can test if that move breaks our integration build? Wouldn't it suffice to simply do a full local build? As described in https://wiki.eclipse.org/Platform-releng/Platform_Build (In reply to Curtis Windatt from comment #2) > We moved the org.eclipse.pde project to pde.ui a while back. That was a wrong decision. org.eclipse.pde covers pde.ui and pde.build. Moving it to ui I is a layer breaker and an arbitrary decision (could have been moved it to pde.build as well). Having said that and knowing that pde.build is basically dead, I'm fine with the move. But of course this must be done so that the history is preserved. Simply move the current state is a complete no go. (In reply to Dani Megert from comment #11) > But of course this must be done so that the history is preserved. > Simply move the current state is a complete no go. I don't think this is possible. You can move a part of a existing repo to a new repo (as Markus did a while ago) but extracting a part of a repo and adding it to another existing one is IMHO not possible without rewriting all commits in the existing one (which breaks all existing links). We have the history for the feature in the old Git repo which we should keep for a while. Isn't that enough? (In reply to Lars Vogel from comment #12) > (In reply to Dani Megert from comment #11) > > > But of course this must be done so that the history is preserved. > > Simply move the current state is a complete no go. > > I don't think this is possible. I've seen blog posts that describe some methods to do this. Such as this one: http://scottwb.com/blog/2012/07/14/merge-git-repositories-and-preseve-commit-history/ It recommends to create a "third" repository, made up of the two original ones, where the original ones become folders in the new, third repository. Not positive that applies here ... but, sounds like it on the surface. I am not sure it is worth it ... just saying to be sure to google search for methods. I would wonder too ... if we are combining two of the PDE repo is there any reason not to combine all three? Could easily be good reasons not to. I am not saying we should. I just think best to be explicit about it. Also, assuming the reason is to "make it easier to check out everything", and if that is the reason, one way to _maybe_ accomplish that, it to make one repository a sub-module of another. Or, perhaps make both pde.ui, and pde.build submodules of 'pde'. This *might* require changes to our build scripts, not sure. I know Git itself has improved submodules of submodules support since we began using Git. (mainly in that many commands have --recursive option). Users would still need to know to use --recursive, but some recommend you basically always use that "just in case" (unless you know of reasons not to ... and there are reasons for some of our use-cases ... using 'recursive' on aggregator can be good in some cases, but, bad in others, in that users would get get much more than they planned for -- but, is good if doing a local build. While only tangentially related, there is a similar bug 440010 (but, there the plan is to do the opposite ,,, breaking up one repository into several smaller ones). I do not think there is time to do any of this for M3, so changed target to M4. Even then not sure ... depends on how much change in build scripts are needed, and if "worth while", if changes to build scripts needed. Moving all of PDE into one repository makes more sense than I first thought. For unrelated reasons, I was looking at o.e.pde.build repo (and feature) and found that the pde.build.feature is built, but never used. That is, appears in no other feature, and is not included in our repo. So there is sense building it. I've opened bug 480051 to remove it from the build. As described in bug 480051 that leaves only two bundles that we build from that repository. (There are also some examples there, but as far as I can see, we do not build them.) So, I would think the best way to do this is to create a new repository. Not sure what to name it ... something like org.eclipse.pde.repo ? Then it would have directories that corresponded to original repos: feature == o.e.pde original repo bundles == o.e. pde.ui original repo build == o.e. pde.build original repo. Under each of those directories would be whatever original directories there were. (at least for UI ... less sure what can be done about other two). I also do not know if there is a difference in committers that has to be resolved. And, most important, not sure what build implications are :) But, think it would not be more than a couple of days worth of work. (In reply to Dani Megert from comment #11) > Having said that and knowing that pde.build is basically dead, I'm fine with > the move. But of course this must be done so that the history is preserved. > Simply move the current state is a complete no go. Losing the history would be an issue for any future maintenance on PDE Build. None of the active committers have expert knowledge of PDE Build so the history is a very valuable resource for tracking down issues. Having a single committer pool and repository for PDE is fine from an administrative perspective. PDE is operating as a single unit for the most part anyways. After a bit more research on Git, I can merge the eclipse.pde and eclipse.pde.ui repository and keep the full history of both repos. This procedure wadds the full history of eclipse.pde to eclipse.pde.ui (as desired) and creates a new merge commit. Here is the procedure, assuming that you have both repos cloned into ~/git cd ~/git/eclipse.pde.ui git remote add eclipse.pde ../eclipse.pde git merge eclipse.pde/master master # reset pom.xml and .gitignore to origin/master git checkout origin/master -- .gitignore git checkout origin/master -- pom.xml # now move feature project to sub-directory mkdir features mv org.eclipse.pde-feature features # manually add an entry for features/org.eclipse.pde-feature to the pom.xml file # afterwards commit the work in a new merge commit git add . git commit -m "Merged eclipse.pde into eclipse.pde.ui repository" -> Merge completed # Publish result, will add all commits from eclipse.pde to eclipse.pde.ui and the merge commit git push origin master -> Result published I tested this locally and its works fine. If no one objects, I apply it for M6 to the eclipse.pde.ui repo. Afterwards we can remove the feature from eclipse.pde (In reply to Lars Vogel from comment #16) > This procedure wadds the full history of eclipse.pde to eclipse.pde.ui (as > desired) and creates a new merge commit. -> s/wadds/adds Sounds good to me. One reminder of another change we should coordinate (loosely) is the "streams/repositories.txt" file -- this is how our batch job decides which repositories to build (and from which branch). http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/streams/repositories.txt Right? What is, will we need only the master of eclipse.pde.ui and no long eclipse.pde? [And as I see the list now, I wonder if we still need eclipse.pde.build listed there. I recall we "stopped building" something from there, since was never delivered, but don't recall details.] And, remember when we say things like "we can remove the feature from eclipse.pde" -- we mean from only the master branch, right? That is, if we went back to do long term maintenance of any of our Rx_y_maintenance branches, we expect them "to build now, as they built then". Thanks Lars, (In reply to David Williams from comment #18) > Right? What is, will we need only the master of > eclipse.pde.ui and no long eclipse.pde? Correct, after the change in this bug, eclipse.pde is not needed anymore. > [And as I see the list now, I wonder if we still need > eclipse.pde.build listed there. I recall we "stopped building" something > from there, since was never delivered, but don't recall details.] I would suggest to not include any change to eclipse.pde.build in this bug. pde.build is still used and its replacement is discussed in other bugs, e.g., Bug 485429. > And, remember when we say things like "we can remove the feature from > eclipse.pde" -- we mean from only the master branch, right? Yes. (In reply to Lars Vogel from comment #19) > I would suggest to not include any change to eclipse.pde.build in this bug. > pde.build is still used and its replacement is discussed in other bugs, > e.g., Bug 485429. The one I was thinking about was bug 480953. But, yes, the pde.build repo is still in use. According to it's "repo pom" we build <modules> <module>org.eclipse.pde.build</module> <module>org.eclipse.pde.build.tests</module> </modules> And, I agree, no need to include anything about them, in this bug, but, IMHO, we could "move" those two bundles long before Tycho is added to SDK (the bug 485429 you reference) ... and, if that ever happens at all (which I doubt), it would be perfectly valid to 'add' Tycho function. It would not *require* that pde build be removed -- I am pretty sure lots of people still use pde build. I have opened bug 487804 to cover merging pde.build and pde.ui. New Gerrit change created: https://git.eclipse.org/r/66640 (In reply to Eclipse Genie from comment #21) > New Gerrit change created: https://git.eclipse.org/r/66640 This needs to be applied, AFTER the I integrated both repos. David, are you available this 17. Febr.? I could merge both repos in my CET morning and leave 66640 for you to merge. (In reply to Lars Vogel from comment #22) > (In reply to Eclipse Genie from comment #21) > > New Gerrit change created: https://git.eclipse.org/r/66640 > > This needs to be applied, AFTER the I integrated both repos. > > David, are you available this 17. Febr.? I could merge both repos in my CET > morning and leave 66640 for you to merge. Yes. I just realized that we did not yet officially ship Mars.2 and closed it in the sense that we tagged the repos with R4_5_2. At this point the safest thing is to wait until we are really done and then do the merge. This also avoids potential Releng issues in case we have to do an emergency Mars.2 rebuild. Before the move, we should tag the master branch of both repos with e.g. 'before_moving_pde_repo_to_pde_ui'. The proposed procedure from comment 16 will only preserve the history in the master branch but not any maintenance branches. (In reply to Lars Vogel from comment #19) > Correct, after the change in this bug, eclipse.pde is not needed anymore. Wrong, eclipse.pde will continue to be used: - for maintenance builds for branches < R4_6_maintenance - to preserve history of non-master branches - to preserve links in bug comments that point to commits in the old repo Lars, make sure the commit messages for both the "merge" and the "delete" commits contain this bug # and the full git: URL for cloning the other repo. @David, FYI, I'm going to adjust the parent in the feature pom.xml to the following:
<parent>
<groupId>org.eclipse</groupId>
<artifactId>eclipse-platform-parent</artifactId>
<version>4.6.0-SNAPSHOT</version>
<relativePath>../eclipse-platform-parent</relativePath>
</parent>
similar to the parent entries for the existing plug-ins in the eclipse.pde.ui repo. This looks like the best choice to me, please let me know if you disagree.
New Gerrit change created: https://git.eclipse.org/r/67797 Changes are ready, but I cannot push as the "old" commits are rejected by our commit hook. I contacted webmaster for help, here is the email for reference: ------- We are planning to merge the Git history of eclipse.pde into eclipse.pde.ui via https://bugs.eclipse.org/bugs/show_bug.cgi?id=475932. For this I need to push the "old" history of eclipse.pde to eclipse.pde.ui but I get for the "old" commits the messages: hook declined error: git.eclipse.org does not recognize this person as a committer on the project, or this person has not signed a CLA (gid=8791 repo:eclipse.pde.ui): bbauman. error: git.eclipse.org does not recognize this person as a committer on the project, or this person has not signed a CLA (gid=8791 repo:eclipse.pde.ui): cwong. Can this be solved on your side? I would not know how to solve it on my side. ------- (In reply to Lars Vogel from comment #26) > @David, FYI, I'm going to adjust the parent in the feature pom.xml to the > following: > > <parent> > <groupId>org.eclipse</groupId> > <artifactId>eclipse-platform-parent</artifactId> > <version>4.6.0-SNAPSHOT</version> > <relativePath>../eclipse-platform-parent</relativePath> > </parent> > > similar to the parent entries for the existing plug-ins in the > eclipse.pde.ui repo. This looks like the best choice to me, please let me > know if you disagree. I would do it "like the others" for now, but technically, it is best if each pom in a repo point to that "repository's pom" as parent and then the repository pom point to the eclipse-platform-parent. In many cases, makes no practical difference (now) but that's the best way for future flexibility. Gerrit change https://git.eclipse.org/r/67797 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.git/commit/?id=ad69cda946d859024567dfa4ae9e0e4a861c4d26 (In reply to Eclipse Genie from comment #30) > Gerrit change https://git.eclipse.org/r/67797 was merged to [master]. > Commit: > http://git.eclipse.org/c/pde/eclipse.pde.git/commit/ > ?id=ad69cda946d859024567dfa4ae9e0e4a861c4d26 This is the commit which removes the content from eclipse.pde. The following commit is the merge commit which brings the feature into eclipse.pde.ui http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=8de1d86a34b0e598d94494bd3dd958daa3c6a2ce Marking as fixed. Gerrit change https://git.eclipse.org/r/66640 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=31abc40457f9d1a3ee92ac4925fe2d4e81b1f659 org.eclipse.pde-feature is now in eclipse.pde.ui.git |