Gitlab is coming...

[Matthew Brush]

On 2020-04-16 3:43 p.m., Simon Steinbeiss 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 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
> 
> 


Great news! Thanks for working on this guys!

Regards,
Matthew Brush