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.
Platform-releng/Migration To GitHub
Initial ideas are gathered here, but page is not up to date.
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