Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Sep 30, Vlad Glagolev [stealth AT tiberian.ru] wrote:
> On Tue, 29 Sep 2015 18:55:43 -0600
> Sukneet Basuta <sukneet AT gmail.com> wrote:
> > What ever happened to Vlad's new website? Using that as Source Mage's
> > website would be a step in the right direction imo.
> 
> Vlad's new website is in-place, but the migration procedure to Jeremy's
> hardware is on hold because of some RL happening.

It's not Jeremy's hardware, it's the distro's hardware that Jeremy happens
to pay for (except the few times the distro has taken up a donation drive
to cover it). What is installed on it and who has root access to it, etc.
is determined by the distro. That's how it's always been, and that's why
primary distro resources go there and not somewhere else the distro doesn't
control.

> So I still propose to set up temporary proxying from at least
> sourcemage.org and www.sourcemage.org hosts and/or change DNS records
> instead of wasting even more time.

If you currently don't have the time to do the migration, how do you have
the time to maintain it on your hardware? Why would it benefit the distro
to move from its own hardware to yours in that case? Yes, what's on the
distro hardware is old and busted content relatively, but it's at least in
the hands of the distro to do what it wants to with.

> The same goes for bugzilla (bugs.sourcemage.ru), which is up-to-date,
> btw. I would easily backport our chili/redmine bug-reports to XML and
> import them into that bugzilla installation.

How would you do this easily with whatever RL is happening? How is it
easier to do there than on the distro's hardware?

> I'm thinking that putting our primary node of repositories to gitlab is
> a bad idea and strategic mistake in comparison with supporting our own
> multi-mirror infrastructure (which all must be running Source Mage, not
> that RedHat, Fedora, Ubuntu or whatever you happily fire&forget).

In 20 years in this business I have never seen a multi mirror
infrastructure provide one bit of strategic value for a project like this,
especially compared to the overhead it adds. People don't care as long as
they can get their content and the times a single master can't provide that
in today's day and age are so few as to be invisible. We don't need
mirrors for sites with 99.99% uptime already, we need integrated git pull
request functionaliy from a source people are used to interacting with.

Attachment: pgpDe7eRsMX65.pgp
Description: PGP signature