Gitlab is coming...

Olivier Fourdan fourdan at
Fri May 1 18:11:43 CEST 2020

Hi Simon,

This is awesome, I just made a new release of xfwm4 to celebrate and
everything went smoothly! :)

Thanks to everyone involved!

On Fri, 1 May 2020 at 00:49, Simon Steinbeiss <simon at> 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 ->
> Looking forward to your merge requests! ;)
> Enjoy!
> Cheers
> Simon
> On Fri, Apr 17, 2020 at 12:43 AM Simon Steinbeiss <simon at> 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 service will be marked as
>> read-only and all your new code will have to be pushed to
>> .
>> ## 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
>> and are thereby biting a big chunk off our Xfce 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 we will use
>> 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 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 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
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Xfce mailing list