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.
Difference between revisions of "Platform-releng/Migration To GitHub"
(14 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | This page is meant to capture ideas, concerns, evaluations, | + | {{warning|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. | ||
== Goal == | == Goal == | ||
Attract more contributors by using a more known workflow on a popular Platform | 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 [https://www.eclipse.org/projects/handbook/#project-resources-and-services] | ||
+ | |||
+ | # Git on Eclipse Foundation [https://git.eclipse.org] | ||
+ | # Gerrit on Eclipse Foundation [https://gerrit.eclipse.org] | ||
+ | # GitLab on Eclipse Foundation [https://gitlab.eclipse.org] | ||
+ | # GitHub managed by Eclipse Foundation [https://github.com/eclipse] [https://wiki.eclipse.org/Social_Coding/Hosting_a_Project_at_GitHub] | ||
+ | |||
+ | == 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: | ||
+ | * [https://www.atlassian.com/git/tutorials/comparing-workflows Comparing Workflows] | ||
+ | * [https://guides.github.com/introduction/flow/ Understanding the GitHub flow] | ||
+ | * [https://about.gitlab.com/topics/version-control/what-is-gitlab-workflow/ What is GitLab Flow?] | ||
+ | * [https://docs.gitlab.com/ee/topics/gitlab_flow.html Introduction to GitLab Flow] | ||
+ | |||
+ | ==== 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 == | == Concerns == | ||
Line 12: | Line 74: | ||
* 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...) | * 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) | * 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] ... | * ... [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? == | == What needs to be done? == | ||
Line 27: | Line 97: | ||
* The build scripts need to add tags to the GitHub repo | * The build scripts need to add tags to the GitHub repo | ||
* PMI info needs to be changed | * 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] ... | * ... [Please add more missing items] ... | ||
+ | |||
+ | == Changing build Process == | ||
+ | |||
+ | * We have build scripts available [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/mbscripts here]. In theory if you trigger [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/master-build.sh master-build.sh] script you should get a eclipse, equinox and update site along with reports should get created in [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/siteDir 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 | ||
[[Category:Eclipse_Platform_Releng| ]] | [[Category:Eclipse_Platform_Releng| ]] |
Latest revision as of 08:05, 12 March 2022
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