Gitlab is coming...

[Simon Steinbeiss]

Good news everyone!

ToC:
  1) Migration to Gitlab for git hosting (yay)! - timeline
  2) Expect the following features/changes
  3) What doesn't change for now (spoiler alert: Bugzilla) and how does
that work?
  4) Outlook of what is planned next (scrap Bugzilla etc. etc.)
  5) Note for Xfce developers

*TL;DR* On May 1st our existing git.xfce.org service will be marked as
read-only and all your new code will have to be pushed to gitlab.xfce.org.

## 1) Migration cgit/gitolite to Gitlab (April 30, 2020) ##
So it's finally happening - we're finally moving to our own self-hosted
Gitlab instance (on virtual infrastructure kindly sponsored by gandi.net)
and are thereby biting a big chunk off our Xfce 4.16 Roadmap (
https://wiki.xfce.org/releng/4.16/roadmap).
As a starting point we will replace our existing cgit/gitolite setup with
Gitlab - so only the Git server will be changed, we will not be using all
aspects of Gitlab in the first stage of this migration (e.g. bugreports
will remain in Bugzilla). The existing Git hooks that post comments from
Git commits to the corresponding Bugzilla bugreports have served us well in
our old setup and will help keep things inter-connected.
The GitHub mirror will remain in sync as a backup.
However, all new projects we set up will start with Gitlab issues because
ultimately we want to migrate.

## 2) What changes ##
So while many things around Git itself will remain the same for developers
and people who want to try out the code, a few things will also
change/improve. Here are a some of the important changes:
 1) All your Git URLs. Instead of git.xfce.org we will use gitlab.xfce.org
to avoid issues around changed URL paths and SSH fingerprints changing. So
please update your remotes (we will try to provide a simple bash
script/helper until migration day).
 2) No more support for the git:// protocol in Gitlab. Instead you can use
HTTPS and/or SSH.
 3) Less complicated procedure to set up an account: while self-registering
is disabled for now to inhibit spam, we will try to lower the barrier for
contributors to get an account. We are currently considering to provide
GitHub and gitlab.com OAuth support, so you can easily sign up through
those services and we benefit from their spam protection.
 4) Merge requests: Previously you had to attach Git patches or diffs to
Bugzilla reports, now you can fork a repository and do a merge request.
This should also help with feature development in the main repositories:
getting things reviewed and tested before things get merged to master.

## 3) What remains the same ##
You can still clone, fetch and pull code from the old git.xfce.org URLs,
because we'll keep cgit/gitolite around as a read-only copy for now. This
not only ensures people aren't simply confronted with 404s, it also means
people who are used to browsing repositories in the cgit/gitolite UI can
still do so.We will still use Bugzilla for the time being for existing
projects, so new bugreports still go to Bugzilla. There shouldn't be any
confusion because Gitlab issue tracking will simply be disabled for those
existing projects.Also, the documentation will remain in DokuWiki for now.

## 4) Outlook ##
In the next stage of this migration we will surely look at migrating
Bugzilla. We haven't really decided if we want to migrate all issues, only
open ones or none at all. Or whether to keep Bugzilla around forever in
read-only archive sort of way. When we figure this out, we will migrate all
projects to using Gitlab's integrated issue tracking. (Full disclosure: We
wanted to migrate away from Bugzilla already now, but we figured we'd
rather go step by step and actually pull through instead of taking on too
much and crossing the finishing line...)
As mentioned before, we will create all new projects with Gitlab issues
enabled already.
Another aspect we sorely miss now is C.I. We do have a build bot, but it's
not integrated at all in our overall setup. Having C.I. run basic
smoketests for all merge requests will help make sure the Git master
branches are even more stable than now (luckily we have really careful and
experienced developers, otherwise things would break all the time
:)).Finally there may be more features of Gitlab we may end up using, but
we haven't made up our mind about all of them. Plus: migrating stuff is a
lot of work, so we want to make sure we don't take bites that are too big
for us to chew.

## 5) Addendum for Xfce developers and regular contributors ##
If you are a developer working on an Xfce project
 * you will either receive an E-Mail with your credentials between now and
migration day because we have created your account for you or
 * you should reach out to us on #xfce-dev after April 30 so we can set one
up for you.
In any case you need to upload your SSH key to Gitlab so you can push to
your project/s!

Finally: a huge round of applause goes to Romain (Skunnyk) who did
practically all of the heavy lifting in preparing this long-awaited
transition!

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20200417/3001b70a/attachment.html>