The project has 4 servers:

• earlgrey
• tibeti
• greentea
• mocha (not used anymore, and we don't have access to it)

All servers are hosted at the Namur University in Belgium. Our contacts there are Didier and Pollux

All Xfce related services are hosted on these servers:

• Websites (www, wiki, blog etc)
• DNS master
• Mailing Lists
• MX
• Bugzilla
• Git
• ~userdir
• Release manager and archive master
• DNS slave
• backups

We have very old hardware (Sun Fire, Sun V20z etc.), and little or no hardware spares.

Even if we don't update our workflow, we need to get rid of our old servers. We can thank UNamur 100000x for their free hosting for the last decade, but I think we need to find a new sponsor. Maybe Gandi (with m8t) can be a solution.

This can be some cloud services or dedicated servers or something else. We don't need unlimited resources, only 2 or 3 instances with enough ram / cpu / disk and good stability.

On the DNS side, maybe outsource this to a provider.

What do we need : 2 instances (VM are ok), per instances:

• 2/4CPUs
• 6GB Ram
• ~ 50GB Disk

And a backup server. As we can keep our servers at namur, they can serve as a backup site.

• GitLab
  • https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure
  • https://github.com/xmunoz/bugzilla2gitlab
• Phacility
• Jenkins
• Artifactory OSS
• GitHub
• Gitea

We need a VM (Debian) for testing the self-hosted alternatives and the migration workflow. Current POC of Gitea is here: https://gitea.xfce.alteroot.org/xfce

Projects and users

1. Each Xfce project should be placed under specific category — “organization” in terms of gitea. The following organizations should be created: Xfce Core, Xfce Applications, Panel Plugins, Thunar Plugins, Bindings, WWW, Archive. ✔
2. Allow to register for everybody in order to create issues and pull requests ✔
3. Users with higher level of privileges can create their own user repositories (is it possible to do with gitea?) ⇒ Everybody can create a “fork” or a repository by default. We can set MAX_CREATION_LIMIT = 0 to only allow Forks (note: need to handle the “user repo” thing) ✔
4. Users can be added as project collaborators in order to commit to the repo directly (multiple project maintainers): One “owner” team per organization (full admin, by default), one “core” dev team per organization (with write access) + individual dev write access to individual projects (for example panel plugins). ✔
5. Some git hooks/configs are required: deny force push to git master, deny deleting master repo, deny deleting projects from organizations (official categories, see above), (what else?) : Only on “official” repo (not forks), enable “branch protection” + Add denyNonFastforwards = true with a script (not possible via gitea itself) ✔
6. git post-receive hook : use a “hack” by using git template (in ~/.gitconfig ) + symbolic links based on https://discuss.gogs.io/t/global-git-hook-support/777 : ✔
7. Enable github oauth ?

Migration from Cgit

1. All git repos, project descriptions and hooks should be migrated to gitea
2. Cgit could remain in order to provide old GUI. It should work with gitea repos (gitolite will be dropped) so it requires some patches to display user repos properly
3. Keep a git-daemon for the git:/ protocol

Style and GUI

1. Gitea's color scheme should be adapted to Xfce web scheme
2. Integrate the Xfce website header somehow
3. Starting page should redirect to list of organizations unless user is signed in

Migration from Bugzilla

1. Issues link should redirect to bugzilla initially: Done with “External Tracker” option ✔

Gitea hacking

1. Transifex translation commits can be (optionally) hidden from gitea web gui

Migration from Bugzilla

1. Migrate all issues from bugzilla to gitea
2. New “Bugzilla Migration” user should be created as owner of all migrated comments from bugzilla
3. Product categories should be replaced with gitea issue tags (they should be created for each repo)
4. Bug statuses such as duplicate/wontfix/etc should be migrated as default gitea-level tags
5. Bug statuses such as open/closed bugs should be migrated as open/closed issue statuses
6. All attachments (even patches) should be migrated as attachments
7. Write a simple web server which will redirect from old bugzilla pages to new gitea issue pages (there should be a small db with (“bugzilla bug id” <> “repo name”, “repo bug id”) association)