Earlier quoted context omitted.
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.
It's really not that hard: https://help.github.com/articles/creating-a-pull-request-fro...
Debian and GNOME announce plans to migrate communities to GitLab
131–140 of 164 posts
Re: Debian and GNOME announce plans to migrate communities to GitLab
#132Earlier quoted context omitted.
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.
It's really not that hard: https://help.github.com/articles/creating-a-pull-request-fro...
Re: Debian and GNOME announce plans to migrate communities to GitLab
#133I don't actually understand this. Are they referring to the agreements for contributing to GitLab itself, or for contributing to things hosted on GitLab, which surely have nothing to do with the hosting at all?
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'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 to protect a project from "oops I wasn't supposed to contribute that" or "oops, new boss here decided to revoke all our contributions").
I'm also confused why GNOME and Debian would have a problem with a CLA even if it did constitute a transfer of rights, since FSF actually does require you to sign over copyright to them in order to contribute, and GNOME and Debian seem happy to use FSF projects.
Re: Debian and GNOME announce plans to migrate communities to GitLab
#134Earlier quoted context omitted.
Inability to find the valid metrics you want is not justification to use invalid numbers.
These numbers are the most valid numbers we can find and match what we estimate based on other even less exact data (like the version check build into GitLab).
Re: Debian and GNOME announce plans to migrate communities to GitLab
#135Earlier quoted context omitted.
How much do you really care if their marketing department is aggressive? Isn't it better that GitLab is open source and a reasonably good member of the OSS community? Honestly I don't even count those stats as false; Jenkins feels super old and the context weirdness ("Not every enterprise self-hosts a git repository") actually makes sense. If this is the trade to support OSS, it's way better than building a shadow su…
>>> if their marketing department is aggressive? Telling lies /= aggressive. Where advertising makes claims that are objectively false they should be called out. This isn't 'puffing' or hyperbolic opinion. This is saying X is Y. That these lies are in support of an agenda with which many here might agree does not matter.
Re: Debian and GNOME announce plans to migrate communities to GitLab
#136Earlier quoted context omitted.
>>> if their marketing department is aggressive? Telling lies /= aggressive. Where advertising makes claims that are objectively false they should be called out. This isn't 'puffing' or hyperbolic opinion. This is saying X is Y. That these lies are in support of an agenda with which many here might agree does not matter.
It's not a lie. They linked right to an elaboration of that statement.
Re: Debian and GNOME announce plans to migrate communities to GitLab
#137Earlier 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.
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
#138Earlier quoted context omitted.
It's really not that hard: https://help.github.com/articles/creating-a-pull-request-fro...
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.
Re: Debian and GNOME announce plans to migrate communities to GitLab
#139As 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.
Absolutely. There is a near hundred hour startup cost to get into helping gnome, so making this process simpler should really be prioritized.
Re: Debian and GNOME announce plans to migrate communities to GitLab
#140Earlier 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.