Difference between revisions of "Talk:PMC proposals/Move Apertium to Github"

From Apertium
Jump to navigation Jump to search
m (Wiki markup)
Line 1: Line 1:
<h2>Reasons to Switch</h2>
== 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>
<li>More people outside Apertium are far more familiar with Git vs. SVN (especially younger folks, see GCI/GSoC)</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>


<h2>Prevailing Approaches</h2>
== Prevailing Approaches ==
<p>Common pros/cons are excluded for the sake of brevity.</p>
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 (&gt; 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>


<h3>Approach 2</h3>
=== 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 (&gt; 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

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.
  • 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.
  • 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.
  • 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).
Retrieved from "https://wiki.apertium.org/w/index.php?title=Talk:PMC_proposals/Move_Apertium_to_Github&oldid=64655"