Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian and GNOME announce plans to migrate communities to GitLab

about.gitlab.com

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Debian and GNOME announce plans to migrate communities to GitLab

#91

Post by dragonwriter »

sytse wrote: post #71
dominotw wrote: post #65

Earlier quoted context omitted.

From bitrise link > We randomly selected 10,000 apps as a base "2/3 of all enterprises" can only be true if all enterprises are building apps on bitrise.

I do agree that the majority of Bitrise their population is not the enterprise at all. The only other representative data we could find was from BuddyBuild https://www.buddybuild.com/blog/source-code-hosting#selfhost... and has the same problem. You can see that it also isn't enterprise because the vast majority of their respondents is cloud hosted. If there is a better data source we can use I would love to know. It…

> You can see that it also isn't enterprise because the vast majority of their respondents is cloud hosted.

So? I work for a extremely conservative enterprise customer (with strict compliance concerns), and we're still agressively moving to cloud-hosted solutions for most things.

Also, still exclusively using TFVC in TFS for source control.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#92

Post by carussell »

johannes1234321 wrote: post #85
WD-42 wrote: post #67

As someone who has attempted to contribute to the GNOME project, this makes me super happy. The current process is archaic: attaching patch files to weird bug trackers and then sorta just waiting for someone to get back to you... A proper pull request system with code review would lower the barrier of entry for contributions to these projects significantly.

Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.

> a pull system is nice for drive-by contributions

Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that remote, send upstream a message that it's ready for them to pull, and make sure that remote maintains uptime until at least upstream has had an opportunity to pull, at which point you can then do whatever you want with it. It really doesn't make a lot of sense to use this workflow for anything but frequent collaborators, where the setup costs are supposed to pay off later, after you've shared your nth change.

Or did you mean it's nice in the sense that increases the volume of contributors, because there's a long tail of people who are familiar with and only know how to deal in pull requests?

Re: Debian and GNOME announce plans to migrate communities to GitLab

#93

Post by dominotw »

sytse wrote: post #71
dominotw wrote: post #65

Earlier quoted context omitted.

From bitrise link > We randomly selected 10,000 apps as a base "2/3 of all enterprises" can only be true if all enterprises are building apps on bitrise.

I do agree that the majority of Bitrise their population is not the enterprise at all. The only other representative data we could find was from BuddyBuild https://www.buddybuild.com/blog/source-code-hosting#selfhost... and has the same problem. You can see that it also isn't enterprise because the vast majority of their respondents is cloud hosted. If there is a better data source we can use I would love to know. It…

>I do agree that the majority of Bitrise their population is not the enterprise at all.

> We and our competition can easily make that claim since almost all Fortune 500 companies have at least one use of GitHub, GitLab, and Atlassian.

Not sure if you are trolling or are missing the point people are trying to make. You are admitting that you made that conclusion based on wrong data and yet continue to say you claim is correct.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#94

Post by chungy »

johannes1234321 wrote: post #85
WD-42 wrote: post #67

As someone who has attempted to contribute to the GNOME project, this makes me super happy. The current process is archaic: attaching patch files to weird bug trackers and then sorta just waiting for someone to get back to you... A proper pull request system with code review would lower the barrier of entry for contributions to these projects significantly.

Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.

The kernel’s process would be far superior to what GNOME does currently. I’ve simply not sent GNOME patches because they won’t accept them over email, and require using a wonky web interface (bugzilla) with an account to do it instead.

I would really much rather to be able to just do a `git send-email` as many other projects (not just the kernel!) accept.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#96

Post by freedomben »

carussell wrote: post #92
johannes1234321 wrote: post #85

Earlier quoted context omitted.

Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.

> a pull system is nice for drive-by contributions Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that r…

To be fair, a lot of the process you mention is fully automated so to the user it's just a few clicks. Not quite as laborious.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#97

Post by pizza234 »

regularfry wrote: post #31
pizza234 wrote: post #29

Earlier quoted context omitted.

It's not so easy. Which lunch are you talking about? Self-hosted or hosted? I don't think GL will ever have anything much in the hosted sector, for two main reasons: 1. GH's infrastructure is far ahead of GL, and 2. the social factor also affects companies that have private repositories, but also public ones - it wouldn't make sense to only move the private repositories to save money When we think about the self-host…

The way I see it going is that many, many large companies will have a bunch of teams on GitHub (with good reason), with both public and private repos. They will also have a bunch of teams on GitLab instances that have been wildcatted into existence, possibly before GitHub had decent inroads, but more probably so the code doesn't leave the firewall. At some point, a Boss who may or may not have Pointy Hair will look a…

This is very speculative.

Moving a significant part of the infrastructure is no joke, and requires extremely pressuring reasons. Licensing of course is one of those, but it's not necessarily the general case.

When it comes to GL vs. GH, right now, speed is also a factor - try to fork a large project on GH and on GL; the last time I did, I was worried that I triggered a bug on GL, given how long it was taking. I speculate GL will have significant hurdles, since they work in the cloud (GH is on metal, and the reason a lead engineer gave me is speed), and they may have troubles scaling while containing expenses.

I also doubt that there are so many companies with large projects on GH and small, "wildcat" projects on GL - GH dwarfs GL for hosted services.

If and when mass migrations will be a concern, GH will surely have the tooling ready.

Pointy hairs are not really relevant, since they may take any decision (even the opposite) for any whim.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#98

Post by dalore »

akerro wrote: post #6
Dunedan wrote: post #2

I can't help to think that Gitlab is more and more eating Github's lunch. I wonder why we see so little from Github to get out of that situation.

Because github still has 99% of that market. Just look at how many repositories opened by Google, Facebook, Apple, Microsoft, NSA, GCHQ and 100s of others big players are on Github and how many on Gitlab.

People/companies go to GitHub to be social. It's the Facebook of computer code. That's why all the big players are there, so they can share/market themselves. It's also where a lot of programmers put their code so they can show it for interviews. That's why there are so many public repositories there.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#99

Post by carussell »

freedomben wrote: post #96
carussell wrote: post #92

Earlier quoted context omitted.

> a pull system is nice for drive-by contributions Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that r…

To be fair, a lot of the process you mention is fully automated so to the user it's just a few clicks. Not quite as laborious.

I don't know what you're referring to. Not quite as laborious as what? When I mentioned things like "setting up a remote", I was specifically thinking of GitHub and GitLab's web forms. It's as exactly as involved as I outlined above.
Post reply on HN