Re: [Tails-project] GitLab hosting: blocking and very import…

Borrar esta mensaxe

Responder a esta mensaxe
Autor: intrigeri
Data:  
Para: Public mailing list about the Tails project
Asunto: Re: [Tails-project] GitLab hosting: blocking and very important criteria?
Hi,

here are my current thoughts / opinions / feelings on this topic.
I'd be happy to change my mind.

<facilitator hat on>

I'm sending this quickly in order to illustrate how I was envisioning
this process when I sent the email I'm replying to. I'm gambling that
a practical example will help folks participate constructively more
than it'll silence people.

Also, it's great if people +1 what others say, possibly with
amendments or comments: it'll help identify consensus.

</facilitator hat on>

intrigeri:
> Which criteria matter above all to us, to the point that we should
> disqualify options that don't meet all these criteria?


For me to feel comfortable enough with hosting confidential issues on
the GitLab we'll use, I think it must comply with these criteria:

- running FOSS

→ This would eliminate GitLab.com.

- designed to host confidential data

→ This would eliminate Salsa.

- Admins have a super-careful approach to using 3rd-party ("cloud")
services and have confidential data in mind if they elect to use
any such thing for a specific kind of storage or computation.
We are confident that this will remain the case.

→ This would eliminate Salsa and GitLab.com.
I have my doubts wrt. Tor on the long term.

- Timely upgrades

→ In the current state of things, this would eliminate
self-hosting; but our sysadmins might be able to find a way to
solve this.

- Legal resilience

→ IMO this would eliminate Salsa and GitLab.com.

I would also classify the following criteria as blockers:

- We have good communication channels with the sysadmins and
GitLab admins and we are confident this will remain the case.

→ This would eliminate Salsa and GitLab.com.
I have my doubts wrt. Tor on the long term.

- We are confident the sysadmins and GitLab admins will be happy to
discuss our evolving needs in the future and negotiate how their
GitLab can better meet our needs.

→ This would eliminate Salsa and GitLab.com.
I have my doubts wrt. Tor on the long term.

- New contributors can easily register.

→ This would eliminate 0xacab, since it blocks registration from
some very popular email providers.

> Which criteria are not necessarily blockers per se, but are still
> very important to us?


Here are the ones that feel particularly important to me:

- Space limits can be negotiated and bumped if needed.
IMO this is mostly covered by some of the criteria I marked as
blockers above.

→ IMO all options comply except Salsa.

- Long-term viability

I'm not marking this as a blocker because it's not utterly
difficult to migrate from one GitLab CE instance to another one.

→ IMO all options comply to some degree, but I have some concerns
on this front for Tor and self-hosting.

- We're happy to contribute financially to the cost of the service.

→ I would not be happy to see Tails give money to GitLab.com but
I could live with it.

- Cost in terms of labour are reasonable

I'm focusing only on labour here because for Tor, 0xacab, and
immerda, I'm confident we'll easily find a level of financial
contribution that works for all involved parties.

I'm not looking at this aspect from an financial perspective (i.e.
"do we have the financial means to pay people to do this work?"):
I'm not particularly concerned about finding the money.
The bottleneck that bothers me the most is the time of our workers
with the skills and trust level that's needed here. Trading extra
money for extra work time is hard. So the work time we put into
this may result in time we won't be able to put elsewhere.

→ IMO the options that potentially have problems here are:

    - self-hosting, because we have to admin everything


    - immerda, because we are the admins of our own GitLab instance
      (which of course gives us an incomparable level of flexibility);
      immerda would manage the OS and GitLab installation so I expect
      it's mostly a spam management problem. This can be mitigated by
      choosing a different trade-off between "cost of admin" and
      "super smooth way towards a first contribution to Tails"; we can
      change our mind and adjust this trade-off as we want at any
      future time, so in the end I'm not concerned.


    - Tor, because I can see it happen that to keep registration open
      enough for our taste on the long term, we have to get involved
      in moderation (fighting spam) at some point, and then labour
      cost can become similar to being hosted at immerda, except that
      instead of deciding ourselves what the trade-off should be and
      how much work we want to do, we have to negotiate this with
      a partner in the context of a power-imbalanced relationship.



What about you?

Cheers,
--
intrigeri