Talk:PMC proposals/Move Apertium to Github - Revision history

Xavivars: /* Cons */

2018-02-01T17:55:24Z

Cons

2018-01-02T19:10:18Z

Pros

2018-01-02T19:06:39Z

Pros

2018-01-02T19:04:36Z

Pros

2018-01-02T18:31:33Z

Reasons to Switch

2018-01-02T18:22:26Z

Cons

2017-11-04T22:34:39Z

Cons

2017-11-02T06:22:41Z

Prevailing Approaches

2017-11-02T05:58:59Z

Cons

2017-10-31T16:55:35Z

@@ Line 86: / Line 86: @@
 *** <strong>RESPONSE:</strong> 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 (''both pro and con'').
+*** <strong>RESPONSE:</strong> Already happening for most of the people. Almost no-one has the whole SVN repo, but multiple SVN subfolders.
 * Somewhat harder for people who use the meta-repos
 ** <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.

@@ Line 77: / Line 77: @@
 * Granular permissions (not everyone has access to literally everything, especially useful for GCI/GSoC)
 ** <strong>RESPONSE:</strong> Could be considered more bureaucratic
+*** Re-response: not really. Granular permissoins are a (good) option, but it's not mandatory. We could use "org" permissions instead of "repo" permissions
+* Empowerment for package maintainers:
+** They could enforce workflows (code reviews, etc) for specific packages, and accept easily patches from other people (via pull requests) before requesting commit access.
 ==== Cons ====

@@ Line 19: / Line 19: @@
 ==== Pros ====
 * Large-scale editing of e.g. 15 pairs is easy.
-** Partial-con: only if you have the whole repo checked out, which is quite rare
 * There are no meta-repos or submodules to deal with.
 * GitHub’s interface can be used directly.
 * Less need for extremely complicated git commands
 * Possible to do partial checkouts using SVN
+** This removes completely possible pro #1
 ==== Cons ====

@@ Line 19: / Line 19: @@
 ==== Pros ====
 * Large-scale editing of e.g. 15 pairs is easy.
+** Partial-con: only if you have the whole repo checked out, which is quite rare
 * There are no meta-repos or submodules to deal with.
 * GitHub’s interface can be used directly.
 * Less need for extremely complicated git commands
 * Possible to do partial checkouts using SVN
 ==== Cons ====

@@ Line 6: / Line 6: @@
 * Avoids SourceForge’s downtime (not so bad lately)
 * SourceForge gives an awful impression
-* More visibility as an FOSS project (people browse GitHub)
+* More visibility as an FOSS project
+** GitHub has become the de-facto host for open source: people searches for "github apertium" to find apertium's code
 == Prevailing Approaches ==

@@ Line 54: / Line 54: @@
 * All the cons in ''Variant A'', minus:
 ** Repos will be smaller than the massive monorepo
-* Moving a package between release states wrecks its history
+* Moving a package between release states and preserving history is complicated (can be scripted)
-** Or is more complicated to preserve the history ?
 ==== Variant C ====

@@ Line 35: / Line 35: @@
 * Commit access will continue to give write access to everything
 * Contradictory to the Git/GitHub philosophy (bad impression)
+* Given that the usual recovery/fix for repo inconsistencies is to wipe and re-clone, having to re-clone a huge monorepo would greatly exacerbate those kinds of issues
 ==== Variant B ====

@@ Line 55: / Line 55: @@
 * Moving a package between release states wrecks its history
 ** Or is more complicated to preserve the history ?
+==== Variant C ====
+Several repos:
+* One for each of the modules in languages/
+* One for all the released pairs
+* One for incubator
+* One for each of the core tools
 === Approach 2 ===

@@ Line 78: / Line 78: @@
 * GitHub doesn’t provide a nice interface to view repos in a tree format
 ** <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 IMO). This page is automatically generated from the repo tags.
+== Related Concerns ==
+* Mailing lists - should probably be preserved on SourceForge for now until/unless we choose to switch to another solution or self-host them.
+* Existing issues - Sushain volunteers to manually transpose (or find an automatic solution) to moving our existing issues (pretty small #)