Hi,
Thanks everyone who participated in this brainstorming!
I'll reply to Ulrike's questions below. Some of them are close to
topics for which I intend to start dedicated discussions about, so for
now let's see if we can quickly clarify some practical aspects; and if
it gets hairy, I'll probably want to take a step back and think about
how to approach these discussions.
u:
> I also have some more pragmatic/practical questions:
> - What will happen to our encrypted repositories?
Formally speaking, wrt. Git repositories, the scope of this GitLab
migration project is restricted to public ones, so private
repositories (be them encrypted or not) are not supposed to be
migrated initially.
The way I see it, migrating private repositories would require
a dedicated discussion (even if we leave them end-to-end encrypted),
which personally I'd rather postpone, in order to focus for the time
being on the various other — potentially complicated — discussions
this GitLab migration will require.
> - Will the Gitlab instance only be used for tickets related to encrypted
> repositories? How do we guaruantee confidentiality for those? What
> other solutions might there be?
I don't understand your first question as-is, but I can make sense of
it if I ignore "only" in this sentence. Should I?
> - Will the Gitlab instance become our main Git repository home or will
> we still have repositories at immerda.ch?
Good question! tl;dr: I don't know yet and community input may help
us make better decisions on this front.
As a starting point, here's how we defined internally the scope of
this project:
- Make GitLab merge requests the default supported way to handle
code, documentation, and website proposed changes for the main
Tails Git repository
- Make GitLab merge requests the default supported way to handle
proposed changes for some, if not all, of Tails' other public
repositories, including at least: Greeter, Installer,
Upgrader, perl5lib, persistence-setup, verification-extension;
and ideally, submodules of tails.git, such as pythonlib
In order to make GitLab merge requests the "default supported way to
handle proposed changes", the only really viable way is to host the
canonical copy of these repositories on GitLab. Therefore, we must
migrate to GitLab the repositories listed above.
But for our other public repos, the "some, if not all, of Tails' other
public repositories" phrasing intentionally gives us some flexibility,
which IMO is good because it allows us to adjust the exact scope of
the migration to:
- What resources we'll have available to do the work.
- What the community wants.
Personally, at this point:
- I guess that migrating 20 repos won't take significantly
more time than migrating 10. But I could be missing something.
- I believe that migrating all public repos to GitLab would make it
easier to write, update, read, follow, and understand our
contributors documentation.
So if we can, I'd like to migrate all our public repos to GitLab,
except perhaps personal repositories that are a very different
kind of thing.
It's also possible that we later discover extra constraints that lead
us to make exceptions and leave some more stuff at immerda.
> And if yes, what will be the relation between these two homes?
I'm not sure at this point. If we end up leaving some repos at
immerda, I assume the relation would be similar to what we currently
have (we already have 2+ hosting places for our Git repos and thus
need to document the exceptions).
Do you have specific desires, concerns, or fears about this relation?
Cheers,
--
intrigeri
