Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[TB]

First, I would like to thank all past, present and future maintainers of the SageMath infrastructure. This is a hard job, which is not always acknowledged. Somewhere in this thread, or in a related thread, the trac backups were mentioned. It reminded me of the the incident https://www.asmeurer.com/blog/posts/the-sympy-hackerrank-dmca-incident/ where SymPy was wrongfully accused of a copyright violation, and got their docs repo and docs website taken down by GitHub. The issue was resolved, and for more details the above post by Aaron Meurer is a recommended reading. One hint I got from this is that any plan to migrate to a new platform should include a plan to migrate out of this platform. The third point from the lessons learned there is "Make backups of your online data". The source code for Sage and its GH wiki are git repos, so it should be relatively easy to have some kind of a continuous append-only backup off-GitHub. Making backups (in a continuous way ready for migration) of GH issues and PRs seems to be a point that require more work, cf. https://stackoverflow.com/questions/67352788/how-to-backup-or-transfer-my-github-things-other-than-code-pr-issue-wiki and https://docs.gitlab.com/ee/user/project/import/github.html From old previous threads about GH/GL migration, I recall that many indeed wanted to replace trac, but preferred GL over GH. One of the advantages described then is the possibility for self-hosting GL, and easier moving between gitlab.com and self-hosting. In this thread it seems GH is preferred, noting popularity of the platform and CI/CD process. FWIW, I like trac, and even like its web interface over those of GH and GL, but I am not one of the maintainers of the SageMath infrastructure... Regards, TB On 11/09/2022 2:19, Nathan Dunfield wrote: I think moving to GitHub makes total sense.  Every other open-source math project I use regularly is on GH, and there are big network-effect benefits to being where everyone else is as others have already pointed out: easier for others to contribute, easier to get credit for contributions, easier cross references to issues up and downstream, etc.  Given the range of projects that use GH, including those like numpy and scipy whose issue/PR counts are similar to the number Sage trac tickets, I'm sure any technical or workflow issues have already been overcome by others and the solutions are likely even documented.  Given the open-source community's reliance on GH, any serious misbehavior on GH's part would result in a massive pushback and, if necessary, a concerted effort by a huge number of people to work out an alternative. Nathan -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/59ec7a86-18c7-4296-84d9-04c250ec27b6n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d5f7f9fe-4e7c-41c9-9844-6c85523bc3ff%40gmail.com.