Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On Fri, Aug 17, 2018 at 11:12:01PM +0200, Thomas Goirand wrote:
> On 08/17/2018 04:11 PM, Wouter Verhelst wrote:
> > But if we're going to
> > be using an external cloud provider for such things, then it doesn't
> > matter whether that external cloud provider runs a free software cloud
> > implementation or a proprietary one, since we wouldn't have any of the
> > benefits of the free software implementation anyway. In that background,
> > it makes much more sense to use free software which can talk to multiple
> > cloud storage implementations; that gives us the ability to move from
> > one cloud provider to another by simply copying some data followed by
> > the flick of a switch (or "just" that flick, if the free software in
> > question copies the data for you).
> >
> > It is true that the whole "cloud" thing does have some impact on free
> > software, and it is indeed also true that this is something that should
> > be considered when deciding on a strategy; however, it is *not* correct
> > to assume that a cloud provider which uses free software is in any way
> > less of a problem in that context than a cloud provider which does not.
> > Both are cases of you relying on a third party for part of the service
> > which you provide, and so there is no real difference.
>
> Wouter, I very much do not agree with your argumentation. Please read
> this video:
You mean watch, I take it? ;-)
> https://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/2018-07-30/server-freedom-why-choosing-the-cloud-op.webm
>
> Having the underlying infrastructure to fully run free software is super
> important, for many reasons. For example, because you can completely
> reproduce it on your own hardware if you feel like it's the correct
> thing to do, and then migrate your data to it. Also, using a free
> implementation avoids vendor lock-in, and provides proven (and tested on
> a CI, for the case of OpenStack) interoperability.
That does make sense. However, if the free software on top of whatever
cloud infrastructure we choose to use already supports multiple cloud
providers (as is the case here), then you already do avoid that same
vendor lock-in.
It would be totally different if we were talking about something that
can only be done by Google Compute Engine; say, if the salsa
administrators wrote the necessary code themselves and did not even
consider looking at a free implementation. Were that the case, I would
agree with you. But that's not what this is about.
> And there's what Jeremy replied to you. We shall not endorse non-free.
>
> I've been fighting for software freedom on the servers for nearly all of
> my professional career, and reading what you wrote makes me really sad.
> IMO you haven't understood what the problem is.
I do; I just don't agree that, *in this specific instance*, it applies.
> Though what I agree very much about, is that we'd get more freedom if we
> were self-hosting fully. One always do.
Exactly. We should encourage that when we can; but we should not fault
the salsa administrators for deciding they don't have the time for that,
and for choosing a third party cloud infrastructure, *for storage only*.
When the cloud provider is used for only a minimal part of the problem
space (as is the case here), and when the software in use allows for
easy switching to another cloud provider (as is the case here), then the
advantages of choosing a cloud provider that uses free software to
provide the required service become very slim indeed. What use is free
software when you can't exercise the rights anyway, as is the case with
a third-party installation of free software cloud infrastructure?
One could say that we might want to do so anyway, for political reasons,
and I would definitely agree with you. But that ship has sailed when we
chose gitlab over the really free software alternatives that also exist.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: