Skip to content

Latest commit

 

History

History
103 lines (81 loc) · 14.6 KB

Github-vs-Gitlab-vs-trac.md

File metadata and controls

103 lines (81 loc) · 14.6 KB

This page compares Github and Trac, focusing on the specific differences that are important to the Sage community.

Github vs trac

A quick overview is given in the table below, a more detailed discussion of these points can be found further below.

Github Trac
Costs Free 1500 Euro / Month ?
Hosting Managed Self-hosted
Synergy effects Largest code host, related projects are also on GH None
Source availability Closed source Open source
CI Free, managed Self-hosted and self-developed (PatchBots)
Activity Actively developed Essentially in maintenance mode
CLI Officially provided Self-developed
IDE integration Provided, e.g. for VSCode None
Familiarity: Newcomers Newcomers are likely familiar with GH Newcomers have likely no prior experience with trac
Familiarity: Existing Most sage developers have a GH account All sage developers are familiar with trac

Moreover, Github and Trac differ in the provided features. Again, a detailed discussion can be found below.

Github Trac
Project Planning Metaticket Issues and Projects Metatickets
2-Factor Auth Yes No
Code snippets Yes: ``` ... ``` Yes: {{{ ... }}}
tbd

In favor of github

  • We are struggling with various aspects of self hosting. Several Sage developers have spent a lot of time over the last months working to upgrade trac and the underlying virtual machine. Hosting on Github means that someone else with more experience and economies of scale is providing this service for us. Moreover, we are currently paying money for trac's servers, while Github is currently free.
  • Github is the largest source code host, making it far more likely to be familiar to new developers than trac. We are losing many potential developers by having a workflow that is unfamiliar to them (though it is hard to measure this effect due to selection bias). Conversely, the use of github is a more transferrable skill, which may help draw in younger developers who may want to build a resume, or donors to Sage.
  • Github provides these features such as:
  • We've already added some continuous integration checks using GitHub Actions to trac; these will be clearer when using Github.
  • Github is actively developed with a very large user base, and new features are being added regularly; trac is far less active (18 posts in 6 threads on their mailing list since the beginning of 2022, all upcoming releases are over a year overdue and mainly seem concerned with updating dependencies rather than implementing new features, their list of users includes many dead links and some that have migrated to other systems like gitlab). With trac becoming less and less maintained we're likely to face further security issues and compatibility issues with other software going forward.
  • Github supports two-factor authentication, reducing the chance of someone sneaking malicious code into Sage.
  • Various Sage dependencies have migrated to github already, making automatic cross repository links helpful when reporting bugs upstream.
  • Since the early 2010s, Sage core developers have been signaling to Sage users/developers that their specialized code would be better off in self-maintained user packages rather than in the Sage library. The vast majority of these Sage user packages are being maintained on GitHub.
  • Due to its popularity, many IDEs provide plugins for Github. For example, it is possible to do the complete fork-clone-branch-pr workflow and review PRs completely from within VS Code without using Github's web interface.

In favor of trac

  • While git and Trac are entirely open source, the GitHub software as a whole is closed source (although GitHub has published many of its components as open source)
  • The Sage development community has long term experience working with trac.
  • Trac has many features:
    • Requesting reviewers through cc, which are explicitly tied to a ticket.
    • Project planning through meta tickets.
    • Navigating code through a web interface (which can be accessed by clicking on the branch).
    • Displaying code snippets.
  • We do not have control of Github's policies, procedures and prices. Github's prices for providing hosting and continuous integration services may increase (they're currently free). Copyright laws can have unfortunate consequences causing downtime and possible legal costs. As a large company, Github has to be more cautious about obeying US export control laws and has thus blocked access in various countries (though it has since restored access in Iran). We could be affected by changes arbitrarily imposed by a 3rd party that affect our workflow.
  • Backing up or migrating issues and wiki pages off of github takes some work, making it harder to switch away from github if they raise prices or make changes that we don't like.
  • Various aspects of the github workflow will be different (the separation of tickets into Issues and PRs for example, switching from git-trac to Github's CLI), requiring current Sage developers to devote time and effort into learning new systems. Many Sage developers like the customized workflow we have developed (new -> needs review -> needs work/need info -> needs review -> positive review -> closed) and like the fact that tickets concentrate comments in one place rather than split into an issue and a PR.

Github vs Gitlab

Some in the Sage community have advocated in the past for using Gitlab rather than Github, including the ability to create merge requests on Gitlab that are mirrored on trac. We chose to make the vote a two-way comparison of Trac and Github for simplicity, choosing Github for reasons described in this section. Note that it is much easier to move between Github and Gitlab than from Trac to either, so we can switch more easily if desired in the future (one of the more difficult aspects, as with the switch from Trac, is associating accounts on the two platforms).

In favor of Github

  • We are heavily invested in using Github Actions, having spent a lot of time incorporating them into our current workflow.
  • While many of the arguments in favor of Github over Trac also apply to Gitlab, the network effect is more pronounced for Github since it is larger.
  • Gitlab has had some site reliability concerns (see this ycombinator thread, which is mostly pro-Gitlab but acknowledges issues).
  • Some Sage developers have struggled trying to set up and maintain mirroring and CI setups on Gitlab.
  • The vast majority of Sage user packages are being maintained on GitHub.
  • Python recently switched from Roundup to Github; the PEP describes their reasoning for choosing Github over Gitlab.

In favor of Gitlab

Mirroring

Some have suggested mirroring Sage on Gitlab as well as Github. Mirroring is not part of this proposal, but could be set up in the future if desired by the community.

Other options

codeberg is another alternative to GitHub/Lab, being very similar in functionality, yet run by a non-profit. Cf. for more options.

Other references

There are many references online about the differences between Github and Gitlab, including the slightly different workflows they use. Here is a sampling.