On Thursday, 7 June 2018 at 05:28:26 UTC, Nick Sabalausky (Abscissa) wrote:
> I've always felt GitLab was better than GitHub (in large part because they're sensible enough to support self-hosting), so it's tempting to use this as a great reason to move to GitLab.

I've been following the discussions (mainly on HN) on the subject, and there are a few arguments against GitLab (i.e. the gitlab.com SaaS) as well.

- The company might be purchased by a bigger one in the same way that happened to GitHub.
- The conflict of interest between the free and paid tiers means that some issues that are useful for open-source projects won't be available to them, even though they are available at their competitors.
- gitlab.com provides features unavailable in the open-source (community) edition to all projects, which means that migrating away from gitlab.com and to a self-hosted instance would be a compromise involving losing features.

> In any case, I've always thought it was absolutely sick that that even though GitHub/BitBucket/GitLab/Launchpad/etc. all provide basically the same features on top of the standard ***distributed*** version control systems, they are all completely incapable of talking to each other or acting as interchangable viewers on a single set of common project data. So much for the "distributed" in "DVCS".

Many people think so too:

https://gitlab.com/gitlab-org/gitlab-ee/issues/4517
https://gitlab.com/gitlab-org/gitlab-ce/issues/4013

Unfortunately it looks like the current plan for federation in GitLab will once again be only in the paid version.

07.06.2018 14:12, Vladimir Panteleev пишет:
> On Thursday, 7 June 2018 at 05:28:26 UTC, Nick Sabalausky (Abscissa) wrote:
>> I've always felt GitLab was better than GitHub (in large part because they're sensible enough to support self-hosting), so it's tempting to use this as a great reason to move to GitLab.
> 
> I've been following the discussions (mainly on HN) on the subject, and there are a few arguments against GitLab (i.e. the gitlab.com SaaS) as well.
> 
> - The company might be purchased by a bigger one in the same way that happened to GitHub.
> - The conflict of interest between the free and paid tiers means that some issues that are useful for open-source projects won't be available to them, even though they are available at their competitors.
> - gitlab.com provides features unavailable in the open-source (community) edition to all projects, which means that migrating away from gitlab.com and to a self-hosted instance would be a compromise involving losing features.
> 
>> In any case, I've always thought it was absolutely sick that that even though GitHub/BitBucket/GitLab/Launchpad/etc. all provide basically the same features on top of the standard ***distributed*** version control systems, they are all completely incapable of talking to each other or acting as interchangable viewers on a single set of common project data. So much for the "distributed" in "DVCS".
> 
> Many people think so too:
> 
> https://gitlab.com/gitlab-org/gitlab-ee/issues/4517
> https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
> 
> Unfortunately it looks like the current plan for federation in GitLab will once again be only in the paid version.
> 

isn't it a niche for THE application that could be written in D?

On 08/06/2018 12:03 AM, drug wrote:
> isn't it a niche for THE application that could be written in D?

I don't think D brings anything to the table when it comes to VCS.

It'll be nicer code, but it won't be noticed by users kind of nice.

On the other hand, Weka.IO does bring a lot to the table...

On Thursday, 7 June 2018 at 05:28:26 UTC, Nick Sabalausky (Abscissa) wrote:
> On 06/03/2018 11:51 PM, Anton Fediushin wrote:
>> 
>> What's your opinion about that? Will you continue using GitHub?
>> 
>
> The obvious question is "Will MS use evil/strongarm shenanigans with GitHub?"
>
> In any case, I've always thought it was absolutely sick that that even though GitHub/BitBucket/GitLab/Launchpad/etc. all provide basically the same features on top of the standard ***distributed*** version control systems, they are all completely incapable of talking to each other or acting as interchangable viewers on a single set of common project data. So much for the "distributed" in "DVCS".

https://joeyh.name/blog/entry/the_single_most_important_criteria_when_replacing_Github/

On Thu, Jun 07, 2018 at 01:28:26AM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d-announce wrote: [...]
> In any case, I've always thought it was absolutely sick that that even though GitHub/BitBucket/GitLab/Launchpad/etc. all provide basically the same features on top of the standard ***distributed*** version control systems, they are all completely incapable of talking to each other or acting as interchangable viewers on a single set of common project data. So much for the "distributed" in "DVCS".

Exactly!!!  Git was built precisely for decentralized, distributed development.  Anyone should be (and is, if they bothered to put just a tiny amount of effort into it) able to set up a git server and send the URL to prospective collaborators.  Anyone is free to clone the git repo and redistribute that clone to anyone else.  Anyone can create new commits in a local clone and send the URL to another collaborator who can pull the commits.  It should never have become the tool to build walled gardens that inhibit this free sharing of code.


> What I've ALWAYS felt we needed, and even moreso now, is a tool to commoditize these "VCS Plus" services. So we can just FORCE the choice of GitHub/BitBucket/GitLab to be "Whatever frontend the user prefers", and everything gets cross-synced and interlinked, etc., and bring the "distributed" back to DVCS, rather than chaining each project to a centralized walled garden.

Yes.


> Keep in mind, if we had been commoditizing and decentralizing repository hosting, issue tracking, PRs, user accounts, etc. right from the start like we should've been, then this MS buyout of GitHub would've been entirely irrelevant to everyone outside GitHub itself. That's what happens with single points of failure. And the reason VCSes even went DVCS in the first place.

Indeed.  Remember the Amazon AWS blackout that affected hundreds (thousands?) of websites?  That's what happens with centralized systems. Yet people just never learn...


T

-- 
Study gravitation, it's a field with a lot of potential.

On Thu, 2018-06-07 at 10:17 -0700, H. S. Teoh via Digitalmars-d-announce wrote:
> […]
> 
> Exactly!!!  Git was built precisely for decentralized, distributed development.  Anyone should be (and is, if they bothered to put just a tiny amount of effort into it) able to set up a git server and send the URL to prospective collaborators.  Anyone is free to clone the git repo and redistribute that clone to anyone else.  Anyone can create new commits in a local clone and send the URL to another collaborator who can pull the commits.  It should never have become the tool to build walled gardens that inhibit this free sharing of code.
> 

I think there is an interesting tension between using a DVCS as a DVCS and no central resource, and thus no mainline version, and using a DVCS in combination with a central resource.  In the latter category the central resource may just be the repository acting as the mainline, or, as with GitHub, GitLab, Launchpad, the central resource provides sharing and reviewing support.

Very few organisations, except perhaps those that use Fossil, actually use DVCS as a DVCS. Everyone seems to want a public mainline version: the repository that represents the official state of the project. It seems the world is not capable of working with a DVCS system that does not even support "eventually consistent". Perhaps because of lack of trying or perhaps because the idea of the mainline version of a project is important to projects.

In the past Gnome, Debian, GStreamer, and many others have had a central mainline Git repository and everything was handled as DVCS, with emailed patches. They tended not to support using remotes and merges via that route, not entirely sure why. GitHub and GitLab supported forking, issues, pull requests, and CI. So many people have found this useful. Not just for having ready made CI on PRs, but because there was a central place that lots of projects were at, there was lots of serendipitous contribution. Gnome, Debian, and GStreamer are moving to private GitLab instances. It seems the use of a bare Git repository is not as appealing to these projects as having the support of a centralised system.

I think that whilst there are many technical reasons for having an element of process support at the mainline location favouring the GitHubs and GitLabs of this Gitty world, a lot of it is about the people and the social system: there is a sense of belonging, a sense of accessibility, and being able to contribute more easily.

One of the aspects of the total DVCS is that it can exclude, it is in itself a walled garden, you have to be in the clique to even know the activity is happening.

All of this is not just technical, it is socio-technical.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, June 07, 2018 20:02:31 Russel Winder via Digitalmars-d-announce wrote:
> On Thu, 2018-06-07 at 10:17 -0700, H. S. Teoh via Digitalmars-d-announce
>
> wrote:
> > […]
> >
> > Exactly!!!  Git was built precisely for decentralized, distributed development.  Anyone should be (and is, if they bothered to put just a tiny amount of effort into it) able to set up a git server and send the URL to prospective collaborators.  Anyone is free to clone the git repo and redistribute that clone to anyone else.  Anyone can create new commits in a local clone and send the URL to another collaborator who can pull the commits.  It should never have become the tool to build walled gardens that inhibit this free sharing of code.
>
> I think there is an interesting tension between using a DVCS as a DVCS and no central resource, and thus no mainline version, and using a DVCS in combination with a central resource.  In the latter category the central resource may just be the repository acting as the mainline, or, as with GitHub, GitLab, Launchpad, the central resource provides sharing and reviewing support.
>
> Very few organisations, except perhaps those that use Fossil, actually use DVCS as a DVCS. Everyone seems to want a public mainline version: the repository that represents the official state of the project. It seems the world is not capable of working with a DVCS system that does not even support "eventually consistent". Perhaps because of lack of trying or perhaps because the idea of the mainline version of a project is important to projects.
>
> In the past Gnome, Debian, GStreamer, and many others have had a central mainline Git repository and everything was handled as DVCS, with emailed patches. They tended not to support using remotes and merges via that route, not entirely sure why. GitHub and GitLab supported forking, issues, pull requests, and CI. So many people have found this useful. Not just for having ready made CI on PRs, but because there was a central place that lots of projects were at, there was lots of serendipitous contribution. Gnome, Debian, and GStreamer are moving to private GitLab instances. It seems the use of a bare Git repository is not as appealing to these projects as having the support of a centralised system.
>
> I think that whilst there are many technical reasons for having an element of process support at the mainline location favouring the GitHubs and GitLabs of this Gitty world, a lot of it is about the people and the social system: there is a sense of belonging, a sense of accessibility, and being able to contribute more easily.
>
> One of the aspects of the total DVCS is that it can exclude, it is in itself a walled garden, you have to be in the clique to even know the activity is happening.
>
> All of this is not just technical, it is socio-technical.

Honestly, I don't see how it makes sense to release any software without a definitive repo. Decentralized source control systems like git are great in that they allow you to have your own fork and do things locally without needing to talk to any central repo and because having folks be able to fork and muck around with stuff easily is incredibly valuable. But actually releasing software that way is a bit of a mess, and there usually needs to be a main repo where the official version of stuff goes. So, the decentralization is great for collaboration, and it removes the need to communicate with the main repo when you don't actually need to, but it really doesn't remove the need for a central repository for the official version of the project.

Whether that central repo needs to be somewhere like github or gitlab or bitbucket or whatever is another matter entirely, but ultimately, I think that the main benefits of DVCS is that it removes the dependency on the central repo from any operations that don't actually need the central repo, not that it removes the need for a central repo, because it really doesn't - not if you want to be organized about releases anyway.

- Jonathan M Davis

On 06/07/2018 04:36 AM, Walter Bright wrote:
> On 6/6/2018 10:28 PM, Nick Sabalausky (Abscissa) wrote:
>> Keep in mind, if we had been commoditizing and decentralizing repository hosting, issue tracking, PRs, user accounts, etc. right from the start like we should've been, then this MS buyout of GitHub would've been entirely irrelevant to everyone outside GitHub itself. That's what happens with single points of failure. And the reason VCSes even went DVCS in the first place.
> 
> Bugzilla for issue tracking is independent of Github.

Yea, it certainly does have that going for it. And I have no real big objections to bugzilla. It would be nice, though, if it were better (and more cleanly) integrated with GitHub/GitLab/BitBucket/etc., and if its data were all distributively stored in git.

Oh, also, just in case I wasn't clear, when I said "if we had been commoditizing and decentralizing..." I meant "we" as in the worldwide programmer community in general, not the D community specifically.

On 6/7/2018 4:00 PM, Nick Sabalausky (Abscissa) wrote:
> Yea, it certainly does have that going for it. And I have no real big objections to bugzilla. It would be nice, though, if it were better (and more cleanly) integrated with GitHub/GitLab/BitBucket/etc., and if its data were all distributively stored in git.

There was some discussion a while back about abandoning Bugzilla and going with Github for issue tracking. In the light of the risk of "all our eggs in one basket" it seems prudent to keep them separate.

Besides, I like Bugzilla and it has served us well.

On 6/7/2018 10:17 AM, H. S. Teoh wrote:
> Exactly!!!  Git was built precisely for decentralized, distributed
> development.  Anyone should be (and is, if they bothered to put just a
> tiny amount of effort into it) able to set up a git server and send the
> URL to prospective collaborators.  Anyone is free to clone the git repo
> and redistribute that clone to anyone else.  Anyone can create new
> commits in a local clone and send the URL to another collaborator who
> can pull the commits.  It should never have become the tool to build
> walled gardens that inhibit this free sharing of code.

We have more on Github than just the source code. There are all the comments that go with the PRs. I have most of this archived, as they get emailed to me by Github, but not all of it and recreating all this priceless historical information into a usable form would be very burdensome.