Re: GitHub could be acquired by Microsoft
On Thu, Jun 07, 2018 at 05:11:40PM -0700, Walter Bright via Digitalmars-d-announce wrote: > 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. And that is why it's a bad thing to build a walled garden around a code repo, esp. when the underlying VCS is well capable of distributed development. If only there has been a standard protocol for communicating such associated content, such as PR comments and discussions, bugs and issues (this latter not applicable in our case, thankfully), then we could have setup an archival system to retrieve and store all of this information. Unfortunately, AFAIK there isn't a way to do this, and so if Github for whatever reason shuts down, all of this valuable information would be lost forever. The same problem faces us if for whatever reason we decide to move to a different VCS hosting provider in the future: the lack of a common, compatible data exchange format for PRs, comments, issues, etc., means that it will be very hard (practically impossible) to export this data and import it into the new system. It's a mild form of vendor lock-in. Mild in the sense that we can take the code with us anytime, thanks to the way git works, but the valuable associated information like PR discussions is specific to Github and there is no easy way (if there's a way at all!) to export this data and import it elsewhere. It's 2018, and history has shown that standard, open data formats are what stands the test of time. We *could* have had a standardized interchange format for representing PR discussions, standard vendor-agnostic protocols for bug-tracking, PR merging, etc.. Yet we're still stuck in the 1998 mindset of building walled gardens that lock us into an inescapable dependence on a specific vendor. Thankfully git allows at least the code to be free from this lock-in, but still, as you said, priceless historical information resides in data that only exists on Github, and the lack of common protocols means we're bound to Github by the fear of losing this data forever if we leave. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: GitHub could be acquired by Microsoft
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.
Re: GitHub could be acquired by Microsoft
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.
Re: GitHub could be acquired by Microsoft
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.
Re: GitHub could be acquired by Microsoft
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
Re: GitHub could be acquired by Microsoft
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 Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: GitHub could be acquired by Microsoft
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.
Re: GitHub could be acquired by Microsoft
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/
Re: GitHub could be acquired by Microsoft
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...
Re: GitHub could be acquired by Microsoft
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?
Re: GitHub could be acquired by Microsoft
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.
Re: GitHub could be acquired by Microsoft
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.
DIP 1013--The Deprecation Process--Final Review Begins
The last chance for community feedback on DIP 1013, "The Deprecation Process", is now underway. Please do not leave any feedback in this thread, but rather in the review thread in the General forum: https://forum.dlang.org/post/hwscnvmtrzfcfnppd...@forum.dlang.org Also, please be sure to review the guidelines for the Final Review round before leaving feedback: https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
