Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

On 09/06/2015 09:50 AM, Thomas Orgis wrote:
> 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.

At the very least, this can be a mirror, but I'm proposing that we give
it a shot. Since the "grumpy old folks" can continue to operate the
exact same way they're operating right now. Just modify the .git/config
to point to a different origin.

Additionally, if this takes off in a good way, we can drop one extra
piece of software that we run on our hardware, which can lower the
attack vector for our volunteers to maintain.

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

Yeah, you'd push/pull from the gitlab git repos, instead of
scm.sourcemage.org The rest of the workflow can be whatever we want it
to be. Starting off, probably the same as what we've got now.
Contributions from core devs are allowed directly into master. Or we can
change it and have everyone do pull requests, and await someone else to
merge it, guaranteeing that we've gotten at least two sets of eyes on it
before it made it into master. Some people can work that way, others can
push directly to master. I don't need to define that for you guys :)

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

The chain of trust for "official" changes would be whomever has access
to the repos on gitlab, just like we control access to the repos on
scm.sourcemage.org. That's not any different. The gitlab
accounts/servers just give us a better UI onto the git project, complete
with pull requests, and simplified forking.

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

That's fair, but I've only seen this from smgl contributers, to be
honest. I've never seen it on any of the other open source projects I've
worked on. Granted those aren't linux distros.

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

I don't mean to imply that we should follow the herd with all things.
This is a low risk, potentially high reward move. If it goes badly,
worst case scenario you edit your .git/config and we're back at
scm.sourcemage.org The cost of transition is cheap in both directions.

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

Gitlab is an opensource project, so philosophically it's something I
feel comfortable using SourceMage with. Github would probably get us
greater visibility (https://github.com/SourceMage I have this too), but
I'd rather lend our support and usage to a true Open Source project. We
can mirror on github as well, for a low cost also. The express purpose
of doing it is to make it more useful. Debian also has far greater
resources to do many more things. We've literally got one guy paying for
all this out of pocket. (Not to imply we're not thankful for this.)

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

Yeah, commits would go to gitlab first, and then a webhook would trigger
instant mirroring of it, so scm.sourcemage.org would lag behind barely
at all. It's actually quite difficult to handle it in both directions.

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

If anything, this would make it easier to put more eyes on the things. I
cannot guarantee that it will bring more people, but having a trivial
way for someone who's interested to come in, make a pull request, see
that it's accepted, or commented on, and accepted will probably result
in a better experience than what we've got right now. The number of
people allowed I'm also pretty sure that this won't affect too many of
the things you "ranted" about :)

--
David

> 
> 
> 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.
> 
> 
> 
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>

Attachment: signature.asc
Description: OpenPGP digital signature