Public SourceMage Discussion List

[Vlad Glagolev <stealth AT tiberian.ru>]

On Sat, 3 Oct 2015 04:29:43 -0500
Jeremy Blosser <jblosser-smgl AT firinn.org> wrote:

> 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.

Except now all primary distro resources are on both my and sobukus[0]
servers'. But that's fine. As fine as our @sourcemage.org mail hasn't
been working since 17 Sep. I wouldn't call that 'control', really.

And such complaining in every such discussion sounds _really_ strange.
I'm sure several of us could host it for years without a problem --
sourcemage.org is not facebook.com, not even booking.com. So if you're
suffering from participating in that -- don't.

Personally, I could distribute it on several servers over the globe,
including mine at home, which has been working 24/7 since 2005. 60 mbps
netio included.

> > 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?

It doesn't need what you call maintenance or "maintenance" that happens
to our current distro infrastructure. Once properly set up, it just
works with cosmetic updates of some stuff -- so it doesn't take much
time. While setting up a new infrastructure on another platform from
scratch does.

> 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.

This doesn't make any sense, because the total amount of uptime of
*.sourcemage.ru services (including beta., bugs., mail generation
service, torrent tracker, etc.) is way higher than outdated and
semi-broken infrastructure of our official one (scmweb issue being
broken for months, openhub commit stats hasn't been updated since May
(because of what? a simple move?), broken mailing addressing, broken
mirrors, broken DNS service (one DNS server, are you serious?), just to
name a few).

Are you thinking that all this useless "defense" really costs our
web-presence? I mean non-existence of our web-presence. We will be
celebrating a year soon, since I announced of beta.. And you're still
"protecting" it the wrong way while keeping it rotten. Protecting from
what or who?

> > 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?

Because it's (bugs.) ready and because of the Great Existence of
Automation?

> > 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

big numbers cost nothing in an improperly-managed environment.

our infrastructure is not fault-tolerant at any level, and any tiny
issue causes full blackout of the service we're trying to provide.

of course, it's not a RedHat-subscriptioned service, but still it is our
face.

> 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.

oh really? maybe because we have no users out there? or because even
devs use too much Debian/Ubuntu/CentOS/whatever which makes them _SO_
blind about it.

> 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.

I would appreciate to see the list of these source people then.

[0] Thomas Orgis

--
Vlad Glagolev <stealth AT tiberian.ru>

Attachment: pgpJxHp6Rs9RX.pgp
Description: PGP signature