migrating to GitLab

[Jonas Hahnfeld]

I haven't heard further objections which, for me, means we are going
with GitLab. If you don't agree, now's your final time to speak up.
Otherwise I would like to tackle the migration rather soon to take
advantage of the new opportunities :-)

This leads me to some final considerations:
1) I'm going to disable write access to SourceForge when starting the
migration. Otherwise the two copies will diverge over time, leading to
confusion for everyone. As all old issues are retained, including their
ticket numbers, this shouldn't be a problem: We can just continue
working on them and preferably close the issues over time ;-)

2) I'm not attempting to migrate outstanding patches from Rietveld. As
we'll most probably have some during the switch, they need to be
resubmitted. This shouldn't be a major deal as everybody should be
working with branches already. Right?

3) The idea is to have the "main" repository at GitLab, next to the
issues and merge requests. This leads to the question what to do with
Savannah because git is distributed anyway. I first thought about only
pushing "important" branches and tags to GitLab (master, stable/*,
release/*). Switching platforms would actually be one of the few
opportunities to do so - in particular tags are hard to get rid of.
However most of us are probably going to reuse their local repository,
just updating the URL. While GitLab has options to prevent pushing
certain refs, that's probably not a great idea. So I guess I'll just
push an identical copy to GitLab unless somebody has a better proposal.

Ultimately we can talk about cleaning up the Savannah repo and only
keeping the "important" branches there. This could for example be
coupled with automated mirroring, which GitLab supports out-of-the-box. 
I won't look into this for the initial switch though, so just make sure
you're not pushing conflicting commits there...

4) I expect the script to take 9-10 hours for the issue migration which
I plan to run over night (European time). This is primarily for post-
processing tasks at the end which are better done when fully awake. So
no issue tracker during this time, but that's probably justifiable.

---

And now to the most important task: picking a date when I'm available.
I could do: Sunday evening & Monday; Tuesday & Wednesday; or Wednesday
& Thursday.

Cheers
Jonas

signature.asc
Description: This is a digitally signed message part