Migrating Wayland & Weston to GitLab

[Daniel Stone]

Hi all,

On 29 May 2018 at 10:59, Daniel Stone <daniel at fooishbar.org> wrote:
> On 7 May 2018 at 16:59, Daniel Stone <daniel at fooishbar.org> wrote:
>> The first thing to happen is to migrate the central Git push point to
>> GitLab. anongit.fd.o and cgit will still work as read-only mirrors,
>> but you will not be able to push to git.fd.o. This would happen for
>> all of wayland, wayland-protocols, weston and wayland-web. libinput we
>> could move separately, wayland-build-tools is open to discussion (does
>> it still work?), and wayland-java appears to be completely abandoned.
>>
>> All this would require is for everyone with push rights to set up
>> their GitLab account with SSH keys as per the instructions at [0]. On
>> a designated flag day, the push URL would become a GitLab one, and
>> direct pushes to git.fd.o would be rejected. Users would be able to
>> view and fork the repository at gitlab.fd.o, though not necessarily
>> able to do any more than that. Since this is easy and low-impact, I'd
>> propose to do this at the end of this week or early next week, if
>> there are no objections.
>
> I intend to migrate the wayland/wayland-protocols/wayland-web/weston
> repository hosting only (issues disabled, MR submission disabled) this
> evening. Anyone trying to push to git.fd.o will get an error message
> pointing them to the wiki page telling them how to configure their
> remotes and set up their accounts. Anyone having trouble with this is
> welcome to contact me and I can help figure it out.

In addition to the wayland and weston repositories (already migrated),
I migrated the wayland-web repository last night. This now uses GitLab
Pages, which means we can use any kind of static site generator we
would like. Anyone who wants to improve the site is certainly more
than welcome to fork the repository and have a go at improving the
content or system.

> I would like to get the issues migrated as well. In order to do that
> though, we need some more fixes to the 'bztogl' migration tool we've
> been using to push issues from Bugzilla to GitLab, as well as do
> migrations for some other projects which requested to migrate their
> issues a while ago. It also needs a fair few changes in order to fix
> support for Phabricator task import as well.
>
> But even once those are done, we need to clean up the bugs we're
> importing. The plan is to only import open bugs: closed bugs will stay
> in Bugzilla/Phabricator forever as a read-only archive, and GitLab
> will only have new active issues. I think a sensible transition plan
> would be for us to aim to do the import at the end of June, which
> means sweeping through all our open bugs before then, closing them if
> they're no longer useful or just cleaning up titles/etc to be helpful
> in future.

I've started cleaning through the bugs as well, but would appreciate
all the help I can get.

Cheers,
Daniel