Move from GitHub long-term #41448
Comments
|
I don't see a reason to switch at this moment. If/when Microsoft starts screwing up GitHub, we can always switch then. |
|
Microsoft bought closed source product with closed source company. Microsoft is Open Source company now.
What are the contrary facts? I am not a Microsoft fan, one I left work because IT stack was mostly on Microsoft. But at this point, if they can really be a good buddy, why not. |
|
Maybe we should never have used Github for our projects since it's closed source and now is just the right time to make things right. One of Gitlab's downside is that most people don't have an account and won't even bother to create one for a PR. Maybe that could change now if enough projects move to it. |
|
People, let's wait. The beautiful thing is, we would wait. And watch and IT people flip-out because they don't understand that Microsoft would only refresh GitHub AND GitLab development at this point. And all IT guys flip-out. And move to GitLab. And GitLab development goes through the roof, and it becomes superB over time. We can sit and watch the GitLab grow (https://www.openhub.net/p/gitlab) and receive all kinds of features and become ready for our migration to it. |
You can already import a repo in 1 click (and it must have been that way for a while). |
|
Yes, I think the prudent move right now is to wait and see. Moving an entire community is quite costly in terms of time and effort. We should not rush in to this decision, and should take great care in evaluating our options and the future. People who would like to not use GitHub now due to the ownership are able to send patches over email, or maybe even a link to a patch over IRC. I'm going to close this issue because I don't think we are likely to take any immediate action. I think mirrors and backups are good and smart -- thank you @volth for setting that up. |
|
@grahamc I agree with the overall sentiment, but I would like a bit more community feedback/discussion before closing this issue, if possible. Judging by likes on OP, this is not just me concerned by this, and closing issue would significantly decrease its visibility. |
|
Ok, now as I look closely to interface, seems GitLab has most features I thought was not present. And if discussion is not about Microsoft acquiring GitHub, but about migration to GitLab, because better - I am interested. I am for migrating when it would be solid-prof migration. With issues, and a everything. @yegortimoshenko Can you refer to Pros/Cons articles, Slant in the head message, maybe have a small list of useful to us features? Then if after this issue would be reopened, referred to everyone would know the points. |
|
Initial title did not communicate intent clearly, I'm concerned about moving away from GitHub rather than by specifically going with GitLab. Regarding that tangent, GitLab does have all the features, and Nix highlighting is better in that it properly highlights key pairs outside of attrsets. Say, GitHub doesn't highlight this properly: imports = [ <nixpkgs/pkgs/top-level/all-packages.nix> ];It is unlikely that there would be issues regarding feature set, but sunk cost is obviously huge: there are over 40000 issues and pull requests. GitLab has auto-import that retains interlinking, wikis, etc., that should help, but even then this would be hard to pull off. The main thing going behind this is that Linux distributions have traditionally preferred libre infrastructure and Nix/NixOS/Nixpkgs is a major exception. This is a chance to make things right in regards to that, and this might help migrate more people to NixOS that are reluctant to do so because of less principled stance on centralization and software freedom. |
|
No panic yet! Microsoft loves open-source, reportedly, so perhaps they will open-source GitHub code 🌈 EDIT: BTW I really like GitLab and we use it at my work all the time (full-time open-source). Back then when Nix* went to GitHub, there was no other option getting close in usability (for free). Now it's mainly about the cost to make such a big change (issues, PRs, Borg, etc.), and I hope Microsoft won't make it worth to pay the price... |
|
GitLab announce that they make:
Free "for open source and educational projects, this means unlimited access to current and new features, including Epics, Roadmap, Static Application Security Testing, Container Scanning, and so much more!" "To apply, send a merge request to add your project to a list of open source projects using GitLab Ultimate and Gold." |
|
I've reframed the issue title to only be concerned about long-term decision, and de facto discussion still continues, so reopening just to keep this option on the table. |
|
Additional discussion here: https://discourse.nixos.org/t/github-was-purchased-by-microsoft/313 |
|
In time there would be articles of big communities moving to GitLab and their experience, and then we would get a deep insight. |
|
Updated upper post with list of features provided. |
|
@Anton-Latukha Sadly I don't think NixOS would qualify for that, since there are quite a few paid contributors (@edolstra from LogicBlox IIRC, various consultancies such as @zimbatm's, etc). EDIT: Nevermind, with the new language (https://gitlab.com/gitlab-com/gitlab-ultimate-for-open-source/commit/8bfafd8872ac59b53d22863ba5b500f30be2f726) it should be fine, since there is no "NixOS Gold" or similar. |
|
I am not sure why GitLab is pushed so much, since there is also https://www.atlassian.com/software/views/open-source-license-request.
If NixOS was a company, I would also suggest to try to reduce dependencies for the code review system, the issue system to the point that GitHub would just become dumb storage, but then comes the question: who is willing to do that? If you want to build all the tooling to make everything redundant, multi-cloud, multi-vendor backed, go ahead, I am sure that everyone would want to use it if it is at least as good as GitHub is currently. Let's say Microsoft would do the worst thing possible: deletion of all data on purpose. The probability of that happening is smaller than that of an operational error by GitHub staff (GitHub was never designed as a security fortress). The only effect of that would be more people (including people they might want to hire, because apparently nobody wants to use Windows in a cloud environment) would like them less, which is bad for their stock price. |
Because GitLab has a libre version that we could self-host, and even EE version has all source code available (with JS under a free license), while Atlassian is just as bad as GitHub is in this regard. For example, if you look at software that comes on NixOS install DVD, overwhelming majority of developers of that software will use GitLab, cgit, Pagure, gitweb, gitolite, etc. I would argue there is a reason for why that is the case, and I think by using GitHub we ironically are somewhat alienated from upstream, the larger Linux community and some of the users. This is about setting policy. There are of course other options: Gitea is fully community-driven, @thoughtpolice makes a case for Phabricator. This issue is about moving from GitHub in general, not to GitLab specifically. |
|
Also at this point, it is definite that GitLab would be just a technically superior product onward. The feature that it is free software open for improving it, it would became same magnitude and influence as Linux, or as Emacs. People and companies would work on it, and develop GitLab more, for themselves. It would become the huge feature-full tool. Also Ruby is pretty clean, intuitive, good and simple enough for all people to understand most of the processes, and make in it, at least, something. Last release of Ruby received JIT possibility. WebAssembly. There is a full pack of tech to make Ruby jump fast enough as never before. Now I always sing praises to Ruby. |
|
Linux work happens over clean Git, and mail list. Besides GIT - they are developed on legacy workflows. Which slows development or lessens volume of contributions/contributors. And since development processes of GitLab are using GitLab itself - it makes productivity progression correspond to a power function. |
|
If you say GitLab's import works for every single GitHub's feature, prove it (this is more difficult than just pressing the import button, but you seem to think that it isn't). GitLab's marketing people can say everything. Your other assertion is that the current proprietary tools might stop potential contributors. If you can find 5 people who declare this openly on their website specific to the NixOS project, then this might be an issue, but otherwise it is statistical noise. Certainly not a convincing argument to do a major migration. Only the owner of this repository (or the future one) can set policy. All we can do is provide convincing arguments, which I'd hope the owner of this repository can also think of. By the time the current owner is doing things so terribly bad, someone will fork, so if it's about policy, I think the right policy is to do nothing at all or to wait until someone does all the work to build something that is so convincingly superior that there is no need to discuss anything. In general, that's a thing that I see a lot in open-source projects: people want to discuss a lot. Regarding the pulseaudio policy. What should be the policy for technical decisions? Are we a democracy? Or should we appoint a committee to allow them to make decisions? I think the arguments against pulseaudio are convincing. I think it's great that user shared knowledge on how broken pulseaudio is; something I would have never known if I hadn't used NixOS. Clearly, that person has a superior understanding of PulseAudio compared to me, and probably every other user in our community. Why should we not listen to such a person? Is it just because "all the other distributions are not doing it"? I wonder how a vote amongst people that actually know something about the subject would turn out. I read libcardiacarrest's source code. I am going to guess that 99.5% of NixOS users didn't. People use GitHub, because it works and people like to use it. That's why companies pay money for it. Like I said before, if you want to do a migration, just fork all the infrastructure with whatever group likes your tool of choice and see where people open most of the issues, post most of the patches, etc. If your suggestion is really better, then we should expect more people to use your solution to the point that GitHub becomes a deserted wasteland. At that point one might make it official, but until that day this is little more than an idea. GitLab will never accept patches in the community edition adding SAML support or other enterprise features like more robustness (i.e. all the things that actually make a product valuable). As such, all you are doing is providing free labor to make their enterprise product worth more by squashing bugs in the core of the product. You also seem to be under the impression that there is not going to be any difference between a hosted version of GitLab enterprise by them and something you could run on your own servers; this is a rather naive thought and nobody from GitLab is going to say that they won't have additional proprietary patches running on their systems. If someone would fork GitLab implementing the missing enterprise features, GitLab's revenue would go to zero the moment Amazon thinks the quality of this hypothetical GitLab fork would be high enough. GitLab will just have the same problem as GitHub (lack of VC funds) in a few years with the difference that nobody is going to buy them, because there won't be a second GitHub exit. If you really think GitLab is a superior product, then I'd think you haven't used GitLab for an extended period of time (I have). This thread reminds me a lot of the mailing list vs Discourse issue. |
I have done a test import of a medium-sized community project (2K+ issues, 5300 commits) over to GitLab recently, and it worked really well. Users, issues, pull requests, interlinking, etc. were all imported properly. That only involved pressing the button.
These people are not around because we scared them away. Look at Debian community and you'll find plenty not comfortable with hosting infrastructure on GitHub. Also, as a hypothetical, imagine us using Discord instead of IRC and what would be the effect of that.
It's just an API stub, there's nothing to read. I know for a fact that most people that participated in that thread have done great work in Nixpkgs (including OP) and I wouldn't assume they don't understand the issue or don't understand what libcardiacarrest does.
This is not how collaboration and community projects work.
Demonstrably false: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?label_name%5B%5D=Community+Contribution&scope=all&sort=popularity&state=merged This also seems to get off-topic relatively quickly, with PulseAudio/libcardiacarrest opinions, telling me to fork instead of seeking community decision here, etc. Let's continue in Discourse thread instead? :-) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Slight aside: brevity is a virtue. Please don't use this issue to filibuster about mailing lists, Discourse, Pulseaudio, mail configurations, project governance etc., since probably not many people have the time to read through all of that. I've hidden some of the more off-topic comments. |
|
@edolstra May I ask you to backup the repo with the https://developer.github.com/changes/2018-05-24-user-migration-api/ thing as discussed above and share the result, please?
Please don't use this issue to filibuster about ...
The current messy state of PRs and issues of this repository is the direct result of not using things we filibuster about here and the lack of governance, is it not?
It is also a weekend and I felt like dumping my frustration about said things. I don't think anything except a couple of last messages specifically about notmuch and half the message about PulseAudio (and I marked that specifically) are off-topic. The rate of dumping was surprising even for myself, though.
But, again, as noted in "the off-topic" messages, normally those things would be forked away into separate threads, but this is GitHub, not ML, which, of course, is the fact that is "off-topic" itself.
I've hidden some of the more off-topic comments.
Funnily enough, that made most those messages completely unreadable in the GitHub UI, as if to prove my "off-topic" points.
|
|
|
|
basically everything @oxij said, but I am biased as a notmuch user. The
only reason I found this thread is because I tag messages that have
notmuch in the body. This type of automation and autotagging is just one
of the benefits of running a fully standalone, indexed version of the
repo's issue/pr history. My main issue with Github is that they don't
provide enough email metadata to tag issues and prs properly :(
Thank you @oxij!
|
|
@jb55 You're welcome :)
@ ALL
Btw, meanwhile GitHub Staff fixed the "off-topic" message rendering and id-hash-linking bugs (kudos to me for reporting, kudos to them for fixing :]), so now is the good time to go back and read all of those "off-topic" messages if you haven't got the original notification and haven't read them via the source view yet.
In particular, let me remind you that we still don't have a backup (and, hence, an index) of anything...
As an experiment I poked my head into several PRs since my last message to this thread and posted some links to related work from my index, but that's clearly unmanageable at scale, and I'm missing a bunch of early stuff in my index (and almost everything was invented already in the first 6000 PRs and issues, and I'm missing a bunch of those).
Can anybody with "Member" of the NixOS org check if they can perform https://developer.github.com/changes/2018-05-24-user-migration-api/ ? Maybe it doesn't actually need the "root" access.
|
|
Do we have any member that sees all the teams inside NixOS org without being an owner? (I am almost sure I do not) |
|
Do we have any member that sees all the teams inside NixOS org without being an owner? (I am almost sure I do not)
I've looked at the docs carefully and https://developer.github.com/v3/migrations/orgs/ claims
The Migrations API is only available to authenticated organization owners.
So, the answer is "no" in ether case. =/ Makes little sense to me as the data is public, though.
Anyway. How do I know who are the owners or have access to the owner account? (I.e., whom should I annoy about this issue? I expected @edolstra to be an "Owner", but @edolstra's status says "Member", which makes sense from a security standpoint, I guess, but whom should I annoy about this then?)
Do I have to make a change.org petition to get any reaction on the issue? Please, notice me, senpais!
(In the worst case I can just crawl everything with some bash+curl/python+urllib/ruby+octokit.
E.g.
$ curl -D - https://api.github.com/repos/NixOS/nixpkgs/issues/1/comments
provides a bunch of useful data, but to get all the data I want to index I'd have to make a lot of calls and that would take quite a while with GitHub's rate limits of 60-5000 requests per hour, a bunch of different API endpoints (comments, events, reviews, reactions) and pagination. See https://developer.github.com/v3/. Getting a dump with all that data in a single go would be much better, IMHO.)
|
|
I had an impression that @rbvermaa and @domenkozar have access to the organization administration. There is non-public data, for example some of the access levels. I am not sure there is a sane way to handle review comments; the main discussion is even sanely scrapable, if I look at the HTML code right. |
|
Is it actually important that the access levels stay private? I mean, GitHub decided they are private, but that's not necessarily a decision of NixOS, is it? I would personally very much like to know whom to ping to know eg. who is able to merge PRs in the RFCs repository. And I don't think this security-through-obscurity brings very much: the people who actually have power over the whole org are quite easy to find anyway, and all nixpkgs committers are equally destructive targets currently anyway, as they can all push a commit with a backdoor. |
|
@Ekleog my comment about access levels was an explanation why GitHub has access control for some kinds of export operations, not a point about our hosting platform requirements. |
|
I'm opposed to a premature migration. GitHub has more mindshare than the alternatives, which in turn leads to more contributions and those contributions are vital to this project's health. Given the size of this project and its community we should be late adopters of alternative hosting solutions, not early adopters. |
|
NixOS project currently has enough visibility that GitHub is not really a source of visibility for us. Our PR review backlog is a larger barrier than whatever UI differences there can be, or the hassle of «login with GitHub account» or even «register with email». I think we do need to understand before any migration why it would help creating better review workflow or better review-supporting bots. But if there is a clear benefit and a reason to believe in reasonable availability level, mindshare is not our real problem. |
|
@Gabriel439 I think we're no longer really talking of migration, just of preparing migration in case we need it. Taking the archive organization owners can download from GitHub and make it public would be preparing this migration in case we ever need it, by securing all data. It would also allow people who want to experiment with a migration to go ahead and import the data into another system, which might end up being better than GitHub… but that's not even the major point (to me), I mostly think having a backup of all data can already help in case a random event comes in, and making this backup available to everyone makes searching in it much easier than using the GitHub search bar. |
|
Closing as this issue as discussions better belong on Discourse. We actually had a similar thread over here: https://discourse.nixos.org/t/github-was-purchased-by-microsoft/313/39 |
|
I'd like to mention, for future reference, that github now forces users to use their web UI if they want to interact with pull requests and bugs in large projects. The github API for these features works only in theory; the author of git-bug has found it too fragile for everyday use on large projects like nixpkgs: MichaelMure/git-bug#749 (comment) We should be aware that by selecting a cloud-web platform, people are prevented from choosing a plain-text user interface. The converse is not true: it's quite easy to build a web UI on top of kerneldev-like workflows; sourcehut (https://sr.ht) does exactly this. I think this asymmetry is the main issue, and which particular corporation owns github is sort of a distraction. I bear no ill will towards Microsoft; this is a problem with cloud companies in general and I think we'd run into it no matter who owned github. Bringing github's ownership into the discussion facilitates mischaracterization of those who object to UI-lockin as "simply Microsoft-haters" or something else dismissive like that.
@zimbatm, you've blocked new comments in that thread. Would you care to link to a different one where people can still comment? It would be nice to be able to discuss this issue in a thread where which particular entity owns github is explicitly off-topic. I think you'd get a higher signal-to-noise ratio. |
|
It's a fair data point that is worth mentioning. Just create a new thread if you want to highlight this new issue more widely. Just to re-iterate but the only issue is when the discussion gets nasty. As long as all participants can appreciate that others might value things differently, it's fine. Typically there is only a fixed combination of arguments to make, and then it comes down to values. |
ghost
mentioned this issue
and others
See:
Maybe it's worth looking into hosting a GitLab instance, as GNOME and FreeDesktop projects do.
The text was updated successfully, but these errors were encountered: