Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Sat, 5 Sep 2015 19:00:32 -0500
schrieb David Kowis <dkowis AT shlrm.org>: 

> I've set up https://gitlab.com/groups/SourceMage and mirrored all the
> git repos we've got right now, with some slight name changes to handle
> the single namespace.

Uh? roups/SourceMage#Where's that coming from out of sudden? Didn't we
conclude that we are grumpy old folks who won't jump on those fancy
pulleys? Well, the discussion about moving to github was quite exactly
a year ago. So, let's go for another round, now somewhat after the fact.

> I'm proposing that we use gitlab.com as our primary git entry point for
> a couple reasons:

What does "primary git entry point mean"? Do I need to get an account
there as a developer, pull and commit to a gitlab server? You said
"nothing else" changes. I'm a bit confused about where "else" begins.

Please state clearly what changes for developers. How is the chain of
trust for "official" changes now, still related to our SSH keys we sort
of personally verified? What role do gitlab accounts and the gitlab
servers play there?

> 2. This makes it easier to allow people to contribute to all the things.

> The pull request model is extremely powerful

I understood that people can always send a git-formatted mail and
anyone can integrate the commit to any repo. This is equivalent to
managing pull requests through such a platform right? I am talking
without much experience here, just seeing that git has integrated
support for sending emails around and wondering if anyone uses that
(Linus?).

The rest of my reply gets more into rant land … it may be just polite
to read it anyway.

> and prevalent in almost
> every open source project.

While I don't want to just be bickering, I have to: I hate it when the
world is reduced to the most visible bits and out-of-sight means
does-not-exist. There is a fair number of open source projects that
don't use a distributed version control system, let alone do not
self-host it. And, gosh, there are even projects that might not be that
visible because they ship working software that doesn't have to be
changed every day.

This doesn't mean that one should follow the trend to go fully
distributed with a centralized 3rd party service, up into the clouds,
per se, but I hate it when the decision comes across as "let's follow
the herd" as they must know the only truth. There wouldn't be a Source
Mage project with that philosophy.

Besides, I do see https://github.com/debian, but that's only mirrors,
not the primary entry point. Even with hints like this:

[MIRROR] - send patches to https://lists.debian.org/debian-dak/

Digging further,

        https://github.com/Debian/README.Debian

explains why it might be a good idea for distros to have accounts on
these services and mirrors there, if it eases pushing patches upstream.

But back to the point of having the primary entry point on such a site
and the precedence set by "almost every open source project": How many
OS distros do have their main repo servers with github/gitlab and
the likes? A cursory search only unveils various stuff to support work
with those distros, specific tools, scripts, contributed by various
folks.

> This commonality helps lower the barrier to
> entry.

Let's see if the number of contributors suddenly explodes. I agree that
putting spell submissions on bugzilla to have them rot there is not
good, main issue being the manpower… The centralized decentralized repo
thing might make it easier for interested users to build their own
forks out of existing pull requests.

> Any objections to doing this? Nothing else changes. We will have
> sufficient automated backups, either by a scripted pull, or some API
> calls and webhooks to keep it backed up, so we don't lose any code
> should Gitlab die a horrible death and take everything with them.

What direction is this? Is it scm.sourcemage.org pulling from gitlab? So
commits have to go to gitlab first?

It's clear that I don't really like a linux distro not being
self-hosted. And yes, I am not proud of _not_ running SMGL on my web
servers, but in hard times, other distros seemed more likely work with
a stable stream of those pesky security updates and without the fear of
upgrades not building. We still don't have a multi-spell staged cast* …
and cast as non-root to boot … but that's drifting off topic.

I am trying to pick my battles and will settle for SMGL somehow working
for me, regardless on where the upstream repo resides, although my
paranoia stirs up when now there are certainly a lot more people
involved with root access to lots of scripts that run as root on my
computers now. With a distro with perhaps around a dozen active users
(is this pessimistic? optimistic?) this makes for a pretty targeted
attack vector. With a "normal" distro I would just be one of the sheep,
and there are lots of other sheep who might notice mishap before me.

With the small amount of manpower and the resulting lack of eyes for
the many-eyes idea, I wonder if that isn't an argument for rather
obscure self-hosting. Not good for realiability, but you don't have a
thousand people with casual root access to the servers and we only need
one out of one or two admins being sloppy (or mischievous), not one out
of hundret.


Alrighty then,

Thomas (who's still got that ringing in the ear from RMS about "doing
your computing with your data on your computer" … well, at least on a
computer one manages and has contract with a hoster for, instead of
SaaS)

* The upgrade safety of userspace is something I manage at work using a
  bare GNU/Linux as base system and putting userspace from pkgsrc on
  top, in separate prefixes that a user can select from. I might move
  towards such a system with my on SMGL installs. This would mean that
  a stable basesystem would be what counts and most of the fluff on top
  would not be of interest anymore, instead working on packaging in the
  cross-platform pkgsrc repo. What keeps me from jumping right away is
  the rather specific way of configuring pkgsrc with the rather
  specific Makefile syntax, and paranoid logic getting in the way at
  times. Perhaps sorcery could support installing separate userspaces
  above basesystem in a nice manner? This needs to be a generic
  mechanism, as individual spells outside basesystem very much don't
  really work with INSTALL_ROOT/TRACK_ROOT and friends properly.

Attachment: pgpkbPXGft6gI.pgp
Description: Digitale Signatur von OpenPGP