Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Platform UI/Git Migration

< Platform UI
Revision as of 06:57, 7 July 2011 by Pwebster.ca.ibm.com (Talk | contribs) (Development in Juno)

This is the plan for migrating Platform UI and the graduated Eclipse 4 bundles (modeled workbench and CSS support) to the eclipse.platform.ui.git repo.

Schedule

Date Step
07/06/2011 midnight EDT Freeze contributions to CVS for both Platform UI and e4
07/06/2011 Begin cvs2git migration. Publish converted Git repos. Begin verification.
07/07/2011 Continued verification of git repos. Update map files for builds: 3.7.1, 3.8, 4.2 (4.1.1)

Migration Plan

We've set up some wikis to capture what Platform-Releng is doing overall:

What we have to start with in CVS

  1. Platform UI, almost entirely in /cvsroot/eclipse UI projects to convert
  2. org.eclipse.ui.forms and org.eclipse.ui.browser and their test projects, which are currently worked on under Platform/UA but are included in the eclipse.platform.ui ACL
  3. bug 349150 - Convert Graduated bundles to git Eclipse 4 UI projects that graduated
  4. bug 349150 - Convert Graduated bundles to git Eclipse 4 Runtime projects that graduated
  5. bug 349177 - stitch ui.workbench fork back into main Compatibility workbench fork
  6. bug 349151 - Move e4 UI bundles to git E4 UI projects and experiments
  7. bug 328756 - e4 tooling should move to git This includes all projects in /cvsroot/eclipse e4/org.eclipse.e4.tools

Where everything is going

The details are in the branch scripts, but we end up with 4 repositories for the above. See [#Development in Juno] for details of what branch you should be working on in Juno.

Development in Juno

Using git right now

Right now our build dependencies are:

  1. 3.8 I build
  2. 4.2 I build picks up most content from 3.8
  3. e4 0.12 builds on top of 4.2 I build

Because 3.8 is build first and 3.8 is run as the nightlies, PDE build supports one replacement fetchTag per repo type, and for our nightlies it is GIT=master.

Until we get this resolved, I propose we do our Juno work (4.2 and any 3.8 work that doesn't touch the org.eclipse.ui.workbench) in R4_development. We should do any 3.8 org.eclipse.ui.workbench work in master, and anything that's not workbench related from R4_development I'll merge or cherry-pick across for the 3.8 builds.

Our goal in Juno M2

The main focus our Platform UI's Juno development is 4.2. To that end, we expect to do most of our work on master. It will contain all of the Platform UI plugins as they were in 3.7 except for our forked compatibility layer, org.eclipse.ui.workbench. It will contain all of our Eclipse 4 UI plugins (Modeled Workbench, CSS Support, Eclipse4 Applications) as they were in 4.1. And it will contain the forked compatibility layer.

All work in Juno on any plugins that haven't been deliberately forked (and so far that short list only includes org.eclipse.ui.workbench) should happen in master. So working on JFace in 3.8/4.2 really means working on master.

Any work that needs to be done in the 3.8 org.eclipse.ui.workbench should be done in the R3_development branch. This will be created off of the R3_7 tag.

Platform UI plugins in 3.8

We could simply pick up all plugin changes from master except org.eclipse.ui.workbench. But that would leave your R3_development branch in an odd state (as you would have to depend on your target platform for 3.8 source). The other proposal is to regularly merge work in master into R3_development so that the other plugins are up to date. We haven't made a final decision here.

Development in 3.7.1

All work on plugins for 3.7.1 should be done in the R3_7_maintenance branch off of tag R3_7. It has already been created.

Migration Script

The actual migration steps we'll be following can be found in the e4 migration repo.

It was based on Platform-releng/Juno_Git_Migration_Recipe and enhanced for some of our stickier problems

Back to the top