Hi,
u:
>> What criteria matter to you for choosing the GitLab instance
>> that Tails will use?
A few questions below, to ensure I correctly understand and capture
your thoughts, and I correctly de-duplicate stuff while preparing the
next steps of this discussion.
> - Are user credentials stored on third party infrastructure? Yes, they
> are probably hosted in a datacenter and most of the time we would
> know exactly in which one. But are they hosted using third party cloud
> solutions?
GitLab stores user credentials in its database, so I believe this
question is equivalent to:
Is the GitLab database hosted on third-party infrastructure?
Please correct me if I got this wrong.
> - How much do we trust the maintainers of the instance?
This was raised both by nodens and Ulrike so this section is for the
two of you.
This definitely resonates in me. Still, I'm curious what kind of trust
you mean, because one can trust someone for X but not for Y.
I'm a little bit concerned that this question will resurface later,
when we try to actually use these criteria. But I'm fine with leaving
it as-is for now and we'll see :)
To illustrate, our list of criteria includes some aspects that relate
to trust, without saying so explicitly:
- Long-term viability, i.e. how much do we trust the maintainers'
commitment to keep maintaining this instance?
- Political affinity, which is ill-defined for now, but may relate to
trust wrt. whether the maintainers' political leaning could lead
them to take actions that negatively affect Tails.
- How the maintainers would take into account our (possibly evolving)
needs, which relates to trust in the capacity of maintaining the
sort of relationship in which our needs matter.
Do you have other kinds of trust, or trust in something else,
in mind?
> - Do we have to or do we want to pay to maintain the instance? How much
> would that cost and where would that money come from?
I don't understand the "where would that money come from?" part.
All our server/service hosting costs are currently either paid by Tor
(hosting for 1 server), or paid out of our unrestricted funding.
If the GitLab hosting costs anything, I assume it would be the same.
Or are there other options?
> - How many owners for a project can there be?
AFAIK this is not configurable, so I don't think we can use this as
a criterion to choose one GitLab vs. the other ⇒ I'll tentatively drop
it from the list. Fair enough?
> - How many subprojects can be created? (This is in the case we will use
> the Gitlab instance as our new home and then we might want to create
> repositories for new contributors.)
It seems to me that this question assumes a very specific GitLab
project/repository layout, that AFAIK is not commonly used. If I take
it literally, it's not going to help us compare GitLab instances as
they're all the same in this respect. But I suspect you don't mean to
ask about subprojects specifically; I understand you're wondering
about the possibility for a new contributor to get a repo.
Typically with GitHub/GitLab, a new contributor navigates to the page
of the project they want to work on, clicks "Fork" (+ creates an
account if needed), which by default would create their forked repo
under their own namespace, independently from the GitLab project
that's run by the organization behind the software. So we won't need
to get in the way of new contributors and have them wait for us to
create their repository anymore: they can create their repo
themselves. And if they want to create a brand new repo, that's not
a fork, in order to work on something totally new: most likely they're
better served by creating their own repo under their own namespace
again, until their work gets official enough to be migrated under the
Tails group umbrella.
Still, one important question is what other stumbling blocks there are
along the new contributor's path. For example, some of the hosting
options I've investigated have additional constraints, such as:
- Blocking registration with email addresses hosted by some very
popular email providers
- New users can fork one single repo; they need to ask to get this
limit lifted
Such constraints are part of the information I have been gathering
from the GitLab hosting options I'm investigating; this topic will
definitely resurface.
With this in mind, what would you like to do with this criterion?
Cheers,
--
intrigeri
