• Browse GIT
• View
• Edit
• Upload
• History
• Print

InfrastructureMigration

Ideas on modernizing development infrastructure. This is work in progress and not officially decided yet!

1.  Motivation

Our current development infrastructure is old and does not meet requirements anymore:

• Amount of required behind the scenes maintenance work is too big
• No support for CI/CD
• No support for collaboration like code reviews or contributions from "outside" (pull requests or merge requests)
• The infrastructure is not very actively maintained, which might impose security issues in the future

2.  Options

Criteria for choosing the future development infrastructure

• Software platform is Open Source or there are at least very good reasons to believe that the service will be offered for a long time
• Maintenance burden is low
• Can host a git repo with web view and good integration with the other parts below
• Has CI/CD for builds and tests
• Has a bug tracker
• Has merge requests or pull requests
• Maybe: Migrate the wiki as well?
• What else?

2.1  Codeberg

Codeberg is a non-profit, community-led effort that provides Git hosting and other services for free and open source projects. It is run by a German non-profit association (e.V.) with the purpose to promote the creation, collection, distribution and preservation of Free Content (Open Content, Free Cultural Works) and Free and Open Source Software (FOSS). Codeberg runs on Forgejo (License: GPL3), so self-hosting would also be an option.

Status:

• A mirror of all LyX git repositories exists at https://codeberg.org/LyX-org/
• Importing issues and users from trac would still need to be done. A trajectory via trac2gitea might be an option (Codeberg is able to import from gitea).

Field mapping:

Open questions:

• It seems that forgejo does not support to configure issue workflows (the 'Action' section in trac when modifying tickets), i.e. how to ensure that a version is always set? For initial ticket creation it is possible to specify a template with mandatory fields, but this is not used for further modifications. How can we have something similar as in trac?

2.2  GitLab

GitLab Inc. offers GitLab to paying customers and a less feature rich Open Source variant under the MIT license, so it can be used for self hosting. Another option is using gitlab.com under the free plan.

A test import of the git repository and the bug tracker exists at https://gitlab.com/jkulesza/test_export_import/-/issues. The following shortcomings do still exist:

• Attachments are not imported in the issue, we only see a table with the metadata. This could be fixed with some work
• Mapping of old trac users to GitLab accounts will not be easy for the final import: GitLab accounts need to pre-exist, and we need to know the name mapping.
• GitLab issue numbers do not match trac numbers due to non-contigous trac bug numbers (because of deleted spam reports).

2.3  GitHub

GitHub is not considered due to the following reasons:

• GitHub's own code is not Open Source
• AI generated bug reports that cannot be disabled and generate a lot of work for maintainers.
• GitHub will soon be managed as part of Mcrosoft's AI organisation, indicating that it is seen as a tool to sell more AI, not as a development platzform anymore.

2.4  Categories

Category: Development