Difference between revisions of "Talk:PMC proposals/Move Apertium to Github"
Jump to navigation
Jump to search
m (Wiki markup) |
|||
Line 1: | Line 1: | ||
− | + | == Reasons to Switch == |
|
+ | * GitHub’s excellent issue tracker |
||
− | <ol> |
||
+ | * More people outside Apertium are far more familiar with Git vs. SVN (especially younger folks, see GCI/GSoC) |
||
− | <li>GitHub’s excellent issue tracker</li> |
||
− | + | * More people outside Apertium have GitHub accounts, easier to start-up for a new user |
|
+ | * GitHub’s interface is far superior to SourceForge’s interface |
||
− | <li>More people outside Apertium have GitHub accounts, easier to start-up for a new user</li> |
||
+ | * Avoids SourceForge’s downtime (not so bad lately) |
||
− | <li>GitHub’s interface is far superior to SourceForge’s interface</li> |
||
+ | * SourceForge gives an awful impression |
||
− | <li>Avoids SourceForge’s downtime (not so bad lately)</li> |
||
+ | * More visibility as an FOSS project (people browse GitHub) |
||
− | <li>SourceForge gives an awful impression</li> |
||
− | <li>More visibility as an FOSS project (people browse GitHub)</li> |
||
− | </ol> |
||
− | + | == Prevailing Approaches == |
|
− | + | Common pros/cons are excluded for the sake of brevity. |
|
− | <h3>Approach 1</h3> |
||
− | <p>A monorepo with all the lingustic data, pairs and language modules. Other folders in SVN like the core engine and peripheral tools (e.g. APy) would live in their own repos.</p> |
||
− | <h4>Pros</h4> |
||
− | <ul> |
||
− | <li>Large-scale editing of e.g. 15 pairs is easy.</li> |
||
− | <li>There are no meta-repos or submodules to deal with.</li> |
||
− | <li>GitHub’s interface can be used directly.</li> |
||
− | </ul> |
||
− | <h4>Cons</h4> |
||
− | <ul> |
||
− | <li>The monorepo would be massive (> 3 GB). |
||
− | <ul> |
||
− | <li>Most devs (aside from the couple core devs) would have to use GitHub’s SVN bridge to work on a pair. |
||
− | <ul> |
||
− | <li>This is highly contradictory to working on GitHub</li> |
||
− | <li>People new to Apertium will have to learn SVN, negating some reasons to switch</li> |
||
− | </ul> |
||
− | </li> |
||
− | <li>Diluted usefulness of branches, PRs and hooks</li> |
||
− | <li>GitHub doesn’t necessarily allow repos larger than 1 GB (unclear whether this limit refers to bare repo). If GitHub decides to stop us at some point after we switch, that’s really bad.</li> |
||
− | </ul> |
||
− | </li> |
||
− | <li>Everyone will disable email notifications (“watching” a repo) since there will be too much spam</li> |
||
− | <li>Massive number of issue labels to curate and apply (non-members cannot tag an issue when submitting), reducing the effectiveness of the issue tracker</li> |
||
− | <li>Commit access will continue to give write access to everything</li> |
||
− | <li>Contradictory to the Git/GitHub philosophy (bad impression)</li> |
||
− | </ul> |
||
− | + | === Approach 1 === |
|
+ | A monorepo with all the lingustic data, pairs and language modules. Other folders in SVN like the core engine and peripheral tools (e.g. APy) would live in their own repos. |
||
− | <p>Individual repos for each pair, language module and tools. A couple of “meta-repos” that contain submodules pointing to collections of repos, e.g. <code>apertium-staging</code> would contain ~8 submodules pointing to each of the pairs in SVN’s /staging and <code>apertium-all</code> would have submodules to <code>apertium-staging</code>, <code>apertium-incbuator</code>, <code>apertium-languages</code>, etc. This hierarchy would be maintained via GitHub’s repo tags (a.k.a. “topics”), i.e. apertium-xxx-yyy could be marked with the <code>incubator</code> tag to end up in <code>apertium-incubator</code>.</p> |
||
+ | |||
− | <h4>Pros</h4> |
||
+ | ==== Pros ==== |
||
− | <ul> |
||
+ | * Large-scale editing of e.g. 15 pairs is easy. |
||
− | <li>Usable issue tracker for each repo</li> |
||
+ | * There are no meta-repos or submodules to deal with. |
||
− | <li>Fits into the Git/GitHub philosophy</li> |
||
+ | * GitHub’s interface can be used directly. |
||
− | <li>People who wish to use Git can contribute using that (while it's still possible to use the SVN bridge for those who want that)</li> |
||
+ | |||
− | <li>Familiar branching, PR and hooks that work as expected</li> |
||
+ | ==== Cons ==== |
||
− | <li>Email notifications and watching repos is useful</li> |
||
+ | * The monorepo would be massive (> 3 GB). |
||
− | <li>Granular permissions (not everyone has access to literally everything, especially useful for GCI/GSoC) |
||
+ | ** Most devs (aside from the couple core devs) would have to use GitHub’s SVN bridge to work on a pair. |
||
− | <ul> |
||
+ | *** This is highly contradictory to working on GitHub |
||
− | <li><strong>RESPONSE:</strong> Could be considered more bureaucratic</li> |
||
+ | *** People new to Apertium will have to learn SVN, negating some reasons to switch |
||
− | </ul> |
||
+ | ** Diluted usefulness of branches, PRs and hooks |
||
− | </li> |
||
+ | ** GitHub doesn’t necessarily allow repos larger than 1 GB (unclear whether this limit refers to bare repo). If GitHub decides to stop us at some point after we switch, that’s really bad. |
||
− | </ul> |
||
+ | * Everyone will disable email notifications (“watching” a repo) since there will be too much spam |
||
− | <h4>Cons</h4> |
||
+ | * Massive number of issue labels to curate and apply (non-members cannot tag an issue when submitting), reducing the effectiveness of the issue tracker |
||
− | <ul> |
||
+ | * Commit access will continue to give write access to everything |
||
− | <li>Harder for people who make changes to lots of pairs at the same time (i.e. couple of core devs) |
||
+ | * Contradictory to the Git/GitHub philosophy (bad impression) |
||
− | <ul> |
||
+ | |||
− | <li>Commands are more gnarly (<code>git submodule</code> can be pretty unintuitive) |
||
+ | === Approach 2 === |
||
− | <ul> |
||
+ | Individual repos for each pair, language module and tools. A couple of “meta-repos” that contain submodules pointing to collections of repos, e.g. <code>apertium-staging</code> would contain ~8 submodules pointing to each of the pairs in SVN’s /staging and <code>apertium-all</code> would have submodules to <code>apertium-staging</code>, <code>apertium-incbuator</code>, <code>apertium-languages</code>, etc. This hierarchy would be maintained via GitHub’s repo tags (a.k.a. “topics”), i.e. apertium-xxx-yyy could be marked with the <code>incubator</code> tag to end up in <code>apertium-incubator</code>. |
||
− | <li><strong>RESPONSE:</strong> Possible to mitigate with aliases and cheat sheets</li> |
||
+ | |||
− | </ul> |
||
+ | ==== Pros ==== |
||
− | </li> |
||
+ | * Usable issue tracker for each repo |
||
− | <li>An analogous change to 15 pairs will result in 15 different commits, each repo has its own history.</li> |
||
+ | * Fits into the Git/GitHub philosophy |
||
− | </ul> |
||
+ | * People who wish to use Git can contribute using that (while it's still possible to use the SVN bridge for those who want that) |
||
− | </li> |
||
+ | * Familiar branching, PR and hooks that work as expected |
||
− | <li>Somewhat harder for people who use the meta-repos |
||
+ | * Email notifications and watching repos is useful |
||
− | <ul> |
||
+ | * Granular permissions (not everyone has access to literally everything, especially useful for GCI/GSoC) |
||
− | <li><strong>RESPONSE:</strong> It’s really not that difficult to checkout (<code>git submodule update --recursive --init</code>) and pull updates to a meta-repo (<code>git pull --recurse-submodules</code>) and with aliases it can be even shorter.</li> |
||
+ | ** <strong>RESPONSE:</strong> Could be considered more bureaucratic |
||
− | </ul> |
||
+ | |||
− | </li> |
||
+ | ==== Cons ==== |
||
− | <li>Requires tooling to keep meta-repos up-to-date |
||
+ | * Harder for people who make changes to lots of pairs at the same time (i.e. couple of core devs) |
||
− | <ul> |
||
+ | ** Commands are more gnarly (<code>git submodule</code> can be pretty unintuitive) |
||
− | <li><strong>RESPONSE:</strong> These are super simple scripts based on GitHub’s reliable API. Sushain is willing to write them and Tino is willing to host (and perhaps code review).</li> |
||
+ | *** <strong>RESPONSE:</strong> Possible to mitigate with aliases and cheat sheets |
||
− | </ul> |
||
+ | ** An analogous change to 15 pairs will result in 15 different commits, each repo has its own history. |
||
− | </li> |
||
+ | * Somewhat harder for people who use the meta-repos |
||
− | <li>GitHub doesn’t provide a nice interface to view repos in a tree format |
||
+ | ** <strong>RESPONSE:</strong> It’s really not that difficult to checkout (<code>git submodule update --recursive --init</code>) and pull updates to a meta-repo (<code>git pull --recurse-submodules</code>) and with aliases it can be even shorter. |
||
− | <ul> |
||
+ | * Requires tooling to keep meta-repos up-to-date |
||
− | <li><strong>RESPONSE:</strong> Sushain will though! See this [https://rawgit.com/sushain97/apertium-on-github/master/source-browser.html page] that can be trivially finished to cover all our repos and is a very simple single HTML file (and pretty nice IMO).</li> |
||
+ | ** <strong>RESPONSE:</strong> These are super simple scripts based on GitHub’s reliable API. Sushain is willing to write them and Tino is willing to host (and perhaps code review). |
||
− | </ul> |
||
+ | * GitHub doesn’t provide a nice interface to view repos in a tree format |
||
− | </li> |
||
+ | ** <strong>RESPONSE:</strong> Sushain will though! See this [https://rawgit.com/sushain97/apertium-on-github/master/source-browser.html page] that can be trivially finished to cover all our repos and is a very simple single HTML file (and pretty nice IMO). |
||
− | </ul> |
Revision as of 09:02, 28 October 2017
Contents
Reasons to Switch
- GitHub’s excellent issue tracker
- More people outside Apertium are far more familiar with Git vs. SVN (especially younger folks, see GCI/GSoC)
- More people outside Apertium have GitHub accounts, easier to start-up for a new user
- GitHub’s interface is far superior to SourceForge’s interface
- Avoids SourceForge’s downtime (not so bad lately)
- SourceForge gives an awful impression
- More visibility as an FOSS project (people browse GitHub)
Prevailing Approaches
Common pros/cons are excluded for the sake of brevity.
Approach 1
A monorepo with all the lingustic data, pairs and language modules. Other folders in SVN like the core engine and peripheral tools (e.g. APy) would live in their own repos.
Pros
- Large-scale editing of e.g. 15 pairs is easy.
- There are no meta-repos or submodules to deal with.
- GitHub’s interface can be used directly.
Cons
- The monorepo would be massive (> 3 GB).
- Most devs (aside from the couple core devs) would have to use GitHub’s SVN bridge to work on a pair.
- This is highly contradictory to working on GitHub
- People new to Apertium will have to learn SVN, negating some reasons to switch
- Diluted usefulness of branches, PRs and hooks
- GitHub doesn’t necessarily allow repos larger than 1 GB (unclear whether this limit refers to bare repo). If GitHub decides to stop us at some point after we switch, that’s really bad.
- Most devs (aside from the couple core devs) would have to use GitHub’s SVN bridge to work on a pair.
- Everyone will disable email notifications (“watching” a repo) since there will be too much spam
- Massive number of issue labels to curate and apply (non-members cannot tag an issue when submitting), reducing the effectiveness of the issue tracker
- Commit access will continue to give write access to everything
- Contradictory to the Git/GitHub philosophy (bad impression)
Approach 2
Individual repos for each pair, language module and tools. A couple of “meta-repos” that contain submodules pointing to collections of repos, e.g. apertium-staging
would contain ~8 submodules pointing to each of the pairs in SVN’s /staging and apertium-all
would have submodules to apertium-staging
, apertium-incbuator
, apertium-languages
, etc. This hierarchy would be maintained via GitHub’s repo tags (a.k.a. “topics”), i.e. apertium-xxx-yyy could be marked with the incubator
tag to end up in apertium-incubator
.
Pros
- Usable issue tracker for each repo
- Fits into the Git/GitHub philosophy
- People who wish to use Git can contribute using that (while it's still possible to use the SVN bridge for those who want that)
- Familiar branching, PR and hooks that work as expected
- Email notifications and watching repos is useful
- Granular permissions (not everyone has access to literally everything, especially useful for GCI/GSoC)
- RESPONSE: Could be considered more bureaucratic
Cons
- Harder for people who make changes to lots of pairs at the same time (i.e. couple of core devs)
- Commands are more gnarly (
git submodule
can be pretty unintuitive)- RESPONSE: Possible to mitigate with aliases and cheat sheets
- An analogous change to 15 pairs will result in 15 different commits, each repo has its own history.
- Commands are more gnarly (
- Somewhat harder for people who use the meta-repos
- RESPONSE: It’s really not that difficult to checkout (
git submodule update --recursive --init
) and pull updates to a meta-repo (git pull --recurse-submodules
) and with aliases it can be even shorter.
- RESPONSE: It’s really not that difficult to checkout (
- Requires tooling to keep meta-repos up-to-date
- RESPONSE: These are super simple scripts based on GitHub’s reliable API. Sushain is willing to write them and Tino is willing to host (and perhaps code review).
- GitHub doesn’t provide a nice interface to view repos in a tree format
- RESPONSE: Sushain will though! See this page that can be trivially finished to cover all our repos and is a very simple single HTML file (and pretty nice IMO).