Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Platform-releng/Migration To GitHub
This page is meant to capture ideas, concerns, evaluations, experimentation... that can help the Platform project in moving to GitHub.
Contents
Goal
Attract more contributors by using a more known workflow on a popular Platform
Alternative Platforms
- Which platforms are available?
- What are the pros and cons of the platforms?
Available platforms
Have to adhere to Eclipse Project Handbook [1]
- Git on Eclipse Foundation [2]
- Gerrit on Eclipse Foundation [3]
- GitLab on Eclipse Foundation [4]
- GitHub managed by Eclipse Foundation [5] [6]
Workflow
- Which requirements do we have on the workflow? E.g. how should the history look like?
- How do the current workflow and the GitHub workflow an compare?
- How should the GitHub workflow be used?
External workflow descriptions:
Requirements
- Each commit or merge to master is reviewed
- Each commit (either by direct commit or merge) in master is reviewed separately
** Mickael: -1 to both, I don't think the "commit" grain is a requirement, it's more a nice to have but Platform project wouldn't really be hurt by merging a series of commit that were all reviewed together. IMO, the right grain is not the commit but the "Change" and 1 change == N commits.
- Master has a linear history (i.e. only fast forward merges)?
** Mickael: +1, many of us read the history quite often, multiple times per day.
There are multiple Git workflows possible to implement the required behavior.
Gerrit Workflow
- Create commit with Change-Id FooBar
- Push to Gerrit
- Review
- Amend commit with Change-Id FooBar
- Rebase commit on master HEAD
- Merge commit with Change-ID FooBar to master
Possible GitHub workflow
- Create a branch FooBar
- Push commits to branch FooBar
- Create a pull request to master
- Review
- Push more commits to branch FooBar
- Merge master HEAD into FooBar
- Squash and merge branch FooBar into master to create a single commit in master
** Mickael: not sure "squashing" into a single commit should be a requirement, using "Rebase and merge" several commits would be acceptable. Both should be allowed, at the discretion of the committer who's going to merge the code.
Possible GitHub Fork workflow
- Fork the main repo
- Push commits to a local branch
- Create a pull request to master
- Review
- Push more commits to branch -> Update Fork -> Review
- Accept PR
Concerns
Moving to GitHub is an opportunity but also has drawbacks:
- GitHub code review is not perceived by some committers as good as Gerrit
- GitHub issue tracker is not perceived by some committers as usable at the scale of Platform project (lack of depends on/blocks/clone relations, difficulty to list attachements, linked patches...)
- The process for contributing to Eclipse project via GitHub is currently cumbersome and not productive enough for new contributors (Signed-Off-By requirement cause a lot of noisy descripton and some contributions are abandoned)
- Existing contributors already using Gerrit will have to learn a new process, e.g., I have no idea how to contribute other than via Gerrit
- ... [Please add more missing items] ...
Plan proposal
- Get rid of the "signed-off by" requirement bug 558653
- Move repositories to GitHub
- Allow contributions through issues and PR's
- Tie PR's to Gerrit Changes and Issues to Bugzilla's
What needs to be done?
Generally
- Build scripts need to be able to manipulate (add tag to) GitHub repositories
- ... [Please add more missing items] ...
For each repository
- Some GitHub actions and/or Jenkinsfile need to be added to trigger CI builds
- The aggregator repository needs to change its submodule reference
- The build scripts need to add tags to the GitHub repo
- PMI info needs to be changed
- Updating the Oomph setups and documentation for using it https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
- ... [Please add more missing items] ...
Changing build Process
- We have build scripts available here. In theory if you trigger master-build.sh script you should get a eclipse, equinox and update site along with reports should get created in siteDir folder. But this is broken. This would be a good starting point to understand how the repos are cloned, tagged and how generation reports are done.
Other noteworthy items
- Gerrit and Github https://gerrit.googlesource.com/plugins/github/+/master/README.md