Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

On 9/11/2015 11:01, Jeremy Blosser wrote:
> On Sep 11, Thomas Orgis [thomas-forum AT orgis.org] wrote:
>> Am Sun, 6 Sep 2015 10:55:48 -0500
>> schrieb David Kowis <dkowis AT shlrm.org>: 
>>> 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.
>>
>> About those folks, grumpy and old or not: Isn't there anyone else with
>> at least an opinion about this? I'd expect at least one more reply than
>> my own. What's the census of people who care about Source Mage
>> development?
> 
> I have historically been opposed to things that:
> 
> 1) proposed changing our emphasis on scratching our own itches in favor of
> assigning tasks or changing direction to attract other people
> 
> 2) migration of underlying systems for no clear gain other than "doing
> something different"
> 
> 3) moving our stuff off of things we control *and* have support for without
> sufficient cold redundancy available to avoid any major outages
> 
> 4) using closed products to produce an F/L/OSS distro
> 
> With that in mind, I am fine with the idea of us making a gitlab repo our
> primary entry point for distribution.
> 
> To (1), I don't see the effort here as sufficient to count as distraction,
> and the culture of pull requests has been an industry changing shift on the
> level of using autotools in your development.
> 
> To (2), I think there's a very good chance it would get us some more
> visibility among the kind of people we want contributing to this distro,
> which is a very real problem right now (that "census of people who care
> about Source Mage development").  Historically we've applied to a very
> specific niche who loves us when they find us, but don't tend to find us
> very readily.  Opening a "storefront" in one of those community places is a
> way to get out there without changing anything else we do as a distro.
> 
> To (3), it should be trivial to maintain our existing infrastructure as a
> direct checkout of the gitlab master and switch back to it whenever needed.
> We would likely leave our existing distro struture in place too, so we'd
> keep distributing our own codexes and such.
> 
> To (4), I wouldn't support this on github, but gitlab provides a truly open
> source tool.  They may or may not use that exact release on their community
> site, but on the balance I don't see this contrary with our philosophy.
> 
> Yes, it would change our auth to do pushes, though I doubt we'd have to use
> different keys... you can send the same ssh public key anywhere you want.
> I don't see that as an issue.
> 
>> If we have to pick one, I'd of course go with the Open Source one. But:
>> Gitlab very much looks like Sourceforge in the early times to me. There
>> used to be a community version of that software, too.
> 
> If they ever stopped being truly open source, I would expect us to treat it
> the same way as if they went offline.  We'd go back to full self hosting.
> 
>>> 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.)
>>
>> The least of our problems is the paying for the server (at least I
>> understood Jeremy that way, and if he couldn't affort it anymore, Vlad
>> or me could provide servers, too), IMHO. Since our userbase and
>> developer base is so small, we also do not need much infrastructure or
>> bandwidth.
> 
> Except that we can't hope to grow back to even where we were if we're not
> stable.  A period of downtime right now like the one that led us to more
> professional hosting would likely kill us for good if we were growing at
> all.
> 
> I am not fond of the bill but yes I'd stop paying it if I couldn't cover
> it.  I believe in this distro and even though I don't have a lot of hours
> for it anymore I am trying to make up for it with what support I can.
> 
> I don't see our infrastructure going away with a move like this, though.
> We'd need the same distro size for at least the mirror, we'd still do our
> own distro, etc.  Gitlab would just become the primary entry point for
> commits and code tracking.
> 
>>> 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 :)
>>
>> Well, my main point to the end was that this decision implies giving
>> the hosting duties from people we somewhat know and trust (or people
>> who the person we know trusts)
> 
> Heh.  I *was* the elected PL for a several years and set up a lot of the
> policies we still use, I think the project and I know each other on in our
> own right.
> 
>> to a totally unknown (arbitrarily large) set of people who have no
>> incentive to care about our belongings.
> 
> This is why I'd want to insist we have the ability to flip a switch and go
> back to our existing setup for commits at any time and also part of why I'd
> want us to continue hosting the distribution point ourselves, so we're the
> last to touch anything we provide to users and know what we're sending
> them.
> 
>> I know, it's the new millennium, it's the cloud and everyone trusts
>> everyone and cares for each other's wellbeing. I just wanted to have it
>> said.
> 
> I'm not a big fan of the clouds and some of the things they're forcing on
> us, but it's where we are and if we have a user base out there I want a
> chance to find them.
> 
> https://media.licdn.com/mpr/mpr/shrinknp_200_200/p/3/005/0a1/3d2/069cfce.png

Jeremy covers my concerns and opinions fairly well, so +1 for what he
said. :)

Thomas has valid concerns as well, though for non-confidential data such
as this I believe a public cloud to have merit. Git itself protects us
from out-of-process modifications. I personally have enjoyed GitHub and
the ability that provides for forking and merging with others, even from
my phone while I'm traveling. :)

The only gains I see from migrating to GitLab (with a up-to-date copy
kept on scm.sourcemage.org) are:
1. Easier method for pull/merge requests from those without an SMGL
commit-account that does not rely on e-mail or a bug-tracker.
2. Publicity and visibility.
3. Our SCM is now in a "cloud" and less prone to a single point of
failure (SPoF), though failures will still occur.

If we do move to a project such as GitLab, wouldn't it be better to
utilize the built-in Issue tracker instead of the (now updated) Redmine?
That might be a subject for later, since it's not a requirement of using
GitLab and such.

-Eric

Attachment: signature.asc
Description: OpenPGP digital signature