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

151–160 of 164 posts

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

#151

Post by ubernostrum »

ufo wrote: post #147
ubernostrum wrote: post #133

Earlier quoted context omitted.

I wouldn't expect Gitlab to do something stupid like this today but getting rid of the CLA protects the free software community from Gitlab doing stupid things in the future. I'm confused now about what was in Gitlab's CLA. The CLAs I've signed never transferred rights to someone else, only asserted that I had the right to grant a license and was granting a license I wouldn't later revoke (since the point of a CLA is…

I could have been a bit clearer with what I wrote. I can imagine why someone would ask those questions... > The CLAs I've signed never transferred rights to someone else This is in part because copyright assignment/transfer is tricky and in some jurisdictions it isn't even possible. Instead, CLAs will often grant the company a perpetual license to reproduce, redistribute and sublicense the copyrighted work. Technical…

If FSF can re-license under a more permissive license, then FSF's assignment agreement implicitly allows the contribution to someday be used in proprietary software (since FSF could relicense to BSD or MIT, then someone else could take that code and incorporate it into a proprietary project).

So why doesn't anyone have a problem with the FSF's assignment?

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

#152

Post by [deleted] »

sitharus wrote: post #102
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…

That’s a super complicated way of describing ‘push the fork button’. You really don’t have to worry about all of that.

[deleted]

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

#153

Post by [deleted] »

sitharus wrote: post #102
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…

That’s a super complicated way of describing ‘push the fork button’. You really don’t have to worry about all of that.

[deleted]

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

#154

Post by regularfry »

pizza234 wrote: post #97
regularfry wrote: post #31

Earlier quoted context omitted.

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 specu…

It's not that speculative. It's predictable from the direction the company I work for is going in.

> 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.

"Extremely pressuring reasons" can be as simple as "we don't like that clause in the contract with supplier X, so we now have to move to supplier Y. Yes, I do mean everyone." We've gone through precisely this in another part of our estate, and it triggered a 10 month migration which is still in flight. IP constraints combined with "we must only pay once for a given function" is easily enough.

> 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.

I can only talk about what I can see: an enterprise, where external GH and internally hosted GL both started very small, and have now consolidated into a single GH org and two (or three? not sure) internal GL services. I'd be pushed to guess where more projects currently live.

Relevant to this conversation: as a company, we looked at GH Enterprise, and decided against it. Or probably more accurately, didn't decide for it. I don't know the reasoning (but I suspect cost).

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

Since they are the ones making the decisions, their reasoning is extremely relevant. There is a logic to how they work, it's just not the one engineers on the ground would pick. So, for instance, they probably won't care about speed of forking unless it actually gets in the way of delivery.

Interestingly, one place GL is winning internally is GitLab CI.

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

#155

Post by kochthesecond »

oAlbe wrote: post #139
kochthesecond wrote: post #110

Earlier quoted context omitted.

Absolutely. There is a near hundred hour startup cost to get into helping gnome, so making this process simpler should really be prioritized.

What do you mean? That it takes one hundred hours of experience with the code base to be able to start making contributions?

Learning how to get patches submitted and accepted, and learning vala..

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

#156

Post by throwawaymanbot »

glutamate wrote: post #10

> GitLab, a software product used by 2/3 of all enterprises, ... This claim is false. The linked survey shows that GitLab has a 2/3 market share in self-hosted Git providers. Not every enterprise self-hosts a git repository.

In a different article, GitLab state this very thing. Self-Hosted being the word they themselves used. This PR release was kind of misleading.

Its great that Debian and GNOME are going to be using it however.

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

#157

Post by dominotw »

ShabbosGoy wrote: post #146
dominotw wrote: post #140

Earlier quoted context omitted.

Its not relevant here if its inferior or not. Not counting your competition and declaring yourself as no.1 is dishonest.

I get that. But most likely, that whole spin is the marketing dept's fault. As I said in another comment, they are not technical enough to understand CI/CD and devops terminology.

They are technical enough to evaluate Jenkins and declare it be not worthy enough to be counted as competition, but not technical enough to understand CI/CD.

Seriously?

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

#158

Post by ufo »

ubernostrum wrote: post #151
ufo wrote: post #147

Earlier quoted context omitted.

I could have been a bit clearer with what I wrote. I can imagine why someone would ask those questions... > The CLAs I've signed never transferred rights to someone else This is in part because copyright assignment/transfer is tricky and in some jurisdictions it isn't even possible. Instead, CLAs will often grant the company a perpetual license to reproduce, redistribute and sublicense the copyrighted work. Technical…

If FSF can re-license under a more permissive license, then FSF's assignment agreement implicitly allows the contribution to someday be used in proprietary software (since FSF could relicense to BSD or MIT, then someone else could take that code and incorporate it into a proprietary project). So why doesn't anyone have a problem with the FSF's assignment?

The fsf's copyright assignment is also controversial (at the very least there is the issue that it adds an extra layer of bureaucracy for contributors).

Honestly, I think it only gets a pass because it is the FSF, a nonprofit entity that is probably the most vocal proponent of copyleft licensing out there.

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

#159

Post by marenkay »

jwilk wrote: post #81

The title says "Debian and GNOME announce plans to migrate communities to GitLab" but unless I'm missing something, there's nothing in the article about this supposed migration.

> Debian and GNOME both plan to migrate their communities and open source projects to GitLab

1st paragraph.

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

#160

Post by marenkay »

ausjke wrote: post #126

An active gitea user here, gitlab is too heavy for my person self-hosting site, at the moment, github for social coding, gitea for personal repo, tried but not jumping on gitlab and do not see a need for that.

... pair that with Drone and/or GoCD.

Personally I avoid using GitLab for professional and private use as it is using Omnibus packaging and comes with a whole bunch of software that usually is neatly packaged by any Linux distribution.

Post reply on HN