Fwd: Gitlab is coming...

[Romain Bouvier]

Hey,

FYI, new gitlab users are set as "external", this mean that you have very limited access by default (for example, you can't create forks). We regularly set them as "Internal", and you can ask us on this ML to grant you, this to avoid too many spambot. 
All previous "active" contributors *should* have their commit access on gitlab, please ask us if we forgot someone :)
Also, as a reminder: issue are still handled on our old bugzilla (for now :)).
So create issues on bugzilla, where you can upload a patch (previous behavior), or create a Merge Request on gitlab, and add a link on bugzilla. 
We know this is not ideal, but it's only the beginning ;)

Simon wrote a small blogpost about the migration: https://simon.shimmerproject.org/2020/04/30/xfce-switches-to-gitlab/ (https://simon.shimmerproject.org/2020/04/30/xfce-switches-to-gitlab/)
May 1, 2020 12:50 AM, "Simon Steinbeiss" <simon at xfce.org (mailto:simon at xfce.org?to=%22Simon%20Steinbeiss%22%20<simon at xfce.org>)> wrote:
Hi everyone,
GitLab is here! o/

For the implications and details, please refer to my earlier E-Mail (see below).

For developers: As promised, we have created a very simple script that will change your remotes from git.xfce.org (http://git.xfce.org) -> gitlab.xfce.org (http://gitlab.xfce.org): https://github.com/ochosi/xfce-helpers/blob/master/xfce-migrate-to-gl (https://github.com/ochosi/xfce-helpers/blob/master/xfce-migrate-to-gl)

Looking forward to your merge requests! ;)

Enjoy!
Cheers
Simon
On Fri, Apr 17, 2020 at 12:43 AM Simon Steinbeiss <simon at xfce.org (mailto:simon at xfce.org)> wrote: 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 (http://git.xfce.org) service will be marked as read-only and all your new code will have to be pushed to gitlab.xfce.org (http://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 (http://gandi.net)) and are thereby biting a big chunk off our Xfce 4.16 Roadmap (https://wiki.xfce.org/releng/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 (http://git.xfce.org) we will use gitlab.xfce.org (http://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 (http://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 (http://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/20200501/b9c45d5a/attachment.html>