Gitlab is coming...

[Yousuf Philips]

Thanks for the great news.

Had one suggestion about bugzilla. How about the idea that no new bugs be
filed there and only be filed as gitlab issues, which should make the
transition easier.


On Fri, Apr 17, 2020 at 2:44 AM Simon Steinbeiss <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 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
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20200418/524e59b6/attachment.html>