141–150 of 164 posts
Earlier quoted context omitted.
Last time I checked Jenkins is a modern CI product.
Depends on your definition of modern. I don't really care what you call it, the fact of the matter is that it's slow and an inferior product.
> 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.
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.
Yup, I can’t count how many times I kept bugfixes, improvements, or tweaks to myself because the submission process is too complicated and user hostile. This is honestly a problem with any submission process involving patch files. I’ve submitted a few via mailing list and I can’t express how much I dread seeing source controled this way.
Earlier quoted context omitted.
GitLab being open source and easy to run on your own hardware is a huge "selling" point. I don't think it's helping their income much, but it's growing the community of users and the money will probably come later. It's very hard for GitHub to compete with that. GitHub could introduce CI and other things that GitLab has, but it would be just one extra feature you have to pay for.
> I don't think it's helping their income much Being opensource is not normally an aspect that helps the income, actually the other way around. Opensource is the argument that wins for the customers that appreciate lack of vendor-lock-in.
By being open source and allowing people to run it on their own servers, they can potentially convert a massive amount of people to their platform that otherwise wouldn't make the switch. Now the next time these people don't want to run gitlab on their own servers for whatever reason, they'll use their service. And pay for it. because they know the tools, the logic, the UI etc.
The reason I'm arguing for this is because that's exactly what's happening with me. I'm a very happy github user, but I might need to run something similar on my own servers. If I do, I'll host a gitlab. And then, for my other projects where i don't need to run my own instance, I'll probably just use their webplatform. Because it takes me less time to navigate it now that I've run it.
So i can see myself paying for gitlab some day because they've open sourced it and got me 'hooked' on their product as a result.
Earlier quoted context omitted.
Depends on your definition of modern. I don't really care what you call it, the fact of the matter is that it's slow and an inferior product.
Its not relevant here if its inferior or not. Not counting your competition and declaring yourself as no.1 is dishonest.
Earlier quoted context omitted.
GNOME and Debian wanted to replace some of their infrastructure with Gitlab but before they did that they asked Gitlab to get rid of their CLA. Before this announcement, people contributing to gitlab itself effectively gave full control of copyrights to gitlab but from now on contributors will keep full control of the copyrights for what they contribute. GNOME and Debian are very serious about free software and are w…
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…
> 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. Technically, the original contributor still owns the copyright to the work but the company is still able to use the contribution as part of non free software because the CLA gave them more powers than the original free software license did.
For example, Canonical's CLA[1] contains the following language:
> (b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; provided that this license is conditioned upon compliance with Section 2.3.
> Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date.
Notice how it explicitly mentions that Canonical is allowed to use the contribution as part of non-free proprietary software. I can't find a copy of Gitlab's old CLA now but I guess it had a similar clause somewhere.
> (since the point of a CLA is to protect a project from "oops I wasn't supposed to contribute that" or "oops, new boss here decided to revoke all our contributions")
If the goal is to provide a paper trail ensuring that the contributor had the copyrights to their contribution, you can do that with a simpler certificate of origin document (like Gitlab is doing now) instead of the stronger terms usually found in CLAs.
> since FSF actually does require you to sign over copyright to them in order to contribute
The FSF's copyright assignment is a bit of a special case. It doesn't exist to protect the FSF's interests and is instead focused on making it easier for the FSF to litigate against GPL violators[2]. In particular, the FSF's copyright assignment contract[3] has a clause explicitly binding them to keep the software free and forbidding them from re-licensing it as proprietary software. The worst they could do is re-license it under a more permissive non-copyleft license, like MIT or BSD.
[1] https://www.ubuntu.com/legal/contributors/submit
[2] https://www.fsf.org/bulletin/2014/spring/copyright-assignmen...
[3] http://www.dreamsongs.com/IHE/IHE-110.html (I could only find older versions, you apparently need to email the FSF to get the latest version of the contract)
Earlier quoted context omitted.
Depends on your definition of modern. I don't really care what you call it, the fact of the matter is that it's slow and an inferior product.
One thing that is not modern: Having such an idiotic workflow that one engineer can cause a huge outage and delete stuff from prod db.
Edit: I should add, our build artficats are deployed to staging and NOT production.
Earlier quoted context omitted.
One thing that is not modern: Having such an idiotic workflow that one engineer can cause a huge outage and delete stuff from prod db.
I understand that too. But in my experience, GitLab CI Runner is the fastest for our stack. I've seen build times reduced from 3 minutes to 59 seconds. I can give exact numbers if you want to scrutinize my statement more. Edit: I should add, our build artficats are deployed to staging and NOT production.
I do have a problem with you implying Jenkins is not-modern by saying "depends on your definition of modern". Speed is only one factor. It's not ok to lie and hide behind "our marketing is clueless about our tech."
Earlier quoted context omitted.
I don't understand how this is a response to anything I wrote in my first comment, or the followup that you're directly responding to. Once again, pull requests work exactly as I outlined above.
No one is disagreeing that this is the technical process behind creating a pull request. It just turns out that a number of companies including Github and GitLab are willing to do all of these steps with a few button presses for free for anyone on behalf of any open source project.
And yes, I do appreciate the rare cases when I can just make the change in the web interface of the original project. But most one-time changes I make involve compiling (or at least running) something.