Am I the only one who thinks gitlab is a poor product?
They upgrade every week. Who the hell does that to paying customers? And half of their website functionality doesn't work when they upgrade -- but their upgrade-banner always says "no down time is expected". It is a running joke in my company.
We constantly get error 500 during upgrades. Merge requests don't commit. Rebase feature didn't work till a few weeks back. Gitlab runners get stuck every now and then. I use it everyday because of company policy, but folks, Gitlab is a really poor product. Feels like they test their product on paying customers.
Also, do they even know how good their competition is at? You can't see the what is changed in response to your comment between two MR uploads. You can't add comments on unchanged parts of the code in the diff-view. You can't add comments when you view the diff between two uploads of an MR. My list of complaints is endless.
I'm really sorry to hear about the crappy experience you've had with GitLab. If you'd like to detail some more complaints, I'd love to hear them and open some issues about these things. Feel free to shoot me an email (located in my profile) or reply here. Either way, thanks for the feedback you've provided here.
As far as the frequent upgrades go, we've been using .com as a way of dogfooding GitLab at scale. Sometimes this goes well and other times it doesn't. We're actively working to improve this process so that downtime and breaking changes are less frequent. The end goal is to eradicate both issues so that upgrades are seamless.
Thanks so much for your kind words! We're always trying to improve, so even though some of the comments are negative, it's still good to hear about pain points so we can fix them.
One issue I encounter often-ish is that when I'm on a gitlab page then hit the back button in the browser - I get a bunch of JSON spit onto the page instead of an actual HTML document.
Most likely needs a Vary header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Va...) set to "X-Requested-With"; otherwise the browser will use whatever it has cached for the last request when you hit the back button (and if it was an Ajax request, that's probably going to mean a bunch of JSON).
Huh? Do XHR requests go on the navigation history stack? WTF? Why? And why would any site use the same URIs for API endpoints and frontend/view navigation places? And in that case should the Content-Type (or Accepts) be the main factor?
> Why would any site use the same URIs for API endpoints and frontend/view navigation places?
Simplicity. Ruby on Rails facilitates that approach, for example.
> And in that case should the Content-Type (or Accepts) be the main factor?
Content-Type, yup! Unfortunately Chrome and IE 10 (not sure about Edge) disagree on that.
Without the Vary header, the back button leads to rendering what the server last returned, without taking the Content-Type into account - which is completely nonsensical in my opinion.
Ironically, the section of the HTTP spec they initially referenced in that Chrome bug as justification for closing it as WontFix is precisely the part which explains why Chrome's current behavior is incorrect. Specifically:
> History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
Doesn't matter whether a Vary header is sent or not; when a user clicks the back button they should see exactly what they saw when they previously viewed that page; regardless of whether that content is cached or not.
No, I think the OP is suggesting that the same URL will have been requested in both JSON and HTML formats, and the browser cache is not differentiating between them.
Yes, I understand that, but that seems crazy on multiple levels.
Why the X-Requested-With should be in Vary when the same client did the request? (Yes, I see, Ajax libs populate this field, whereas usual browser navigation doesn't. Makes no sense.)
Why is that resource in cache anyhow, when it should be Cache-Control: no-cache (or at least must-revalidate, but it probably is, but of course that again means that the cache returns the JSON after getting the 304 from the backend, because it doesn't differentiate between responses with different Content-Type)?
It seems to me that the X-Requested-With is again a hack on top of "representational state transfer", because it was easier than trying to use Content-Type.
I mean, I know RoR likes magic very much, but it's not totally surprising to separate the backend from the frontend.
And then use a SPA framework and use Ajax to communicate with the backend via a "REST API", because that simplifies the backend. A lot. You don't have to have views, templates, and so on implemented.
So either the REST API is not a REST API, but a lot of interesting endpoints for the frontend dynamic JS magic, or the frontend is not a frontend, just a lot of glitter thrown up on a REST API.
(I quickly tried to get something in JSON from a GitLab URL, but I just get a HTTP 406. :( )
I've actually experienced this exact thing. Usually a refresh fixes it for me so I never gave it too much thought. I'm not sure what causes it exactly but I'll follow up with the team about it. It usually happens to me on merge requests -- do you notice it on specific pages at all?
> Usually a refresh fixes it for me so I never gave it too much thought.
As someone who hacks on a SaaS with a sprawling feature set which ships often, I understand where you're coming from. But I would recommend giving things like that some thought.
I'm still not really sure, when I press the back button in Android, whether I'm going to stay in the same app, go to a different app, or close the app; all three behaviours are common.
> Am I the only one who thinks gitlab is a poor product?
Not at all.
Some gripes:
- Bad UX, just one example: many things that require one-click + type in competetitors products require more than one click (2-3). Another: Hard to see in the issue tracker which issues were updated.
- Bad notifications: It seriously creates notifications for actions done by oneself. That makes absolutely no sense at all whatsoever.
- Somewhat sluggish performance .... compared to Github!
- Poor review UX
- Annoyingly bad issue listings (e.g. select some issues and change something about them)
... and I've literally only used it in one rather small project. Incidentally no one of the regular users I know are satisfied or ok with Gitlab.
For 2) as the link you posted pointed out it's by default in and for the few that like getting these notifications there's a out-in button. I'd agree that not having this be a default is a little bit bad UX but not having it at all is really bad UX.
> It seriously creates notifications for actions done by oneself. That makes absolutely no sense at all whatsoever.
Ironically I wish this feature existed on Github (does it???). To be more specific, I wish I could get emailed when I make comments on PRs. As crazy as it sounds, it is much easier for me to track whether the comments have been addressed in a list of emails instead of trying to dig through Github's comment interface after I've made many different comments.
Of course this wouldn't be necessary if that compact list just existed in Github already...
> Am I the only one who thinks gitlab is a poor product?
I completely agree. I only use it because it has a CI for private projects for free but that's literally the only reason. The UX is not great (Github PRs are light years ahead of Gitlab merge requests), the overall UI is confusing and is hard to find stuff you want to, it is still extremely slow and lots of downtimes. They have some good ideas but the execution is usually not great.
The only 2 selling points are the free CI and the fact that is open-source but overall I think Gitlab wouldn't be a hard competitor to beat for newcomers.
- Can see new stuff that happened since the last time I was on the PR
- Review mode
- Faster
- Can view rendered file (like .md) without leaving the page
- Commits visible on the main tab
And for a more subjective one: the gitlab feels extremely crowded and a general lack of polish.
Take the right sidebar on a merge request for examples, they are icons since it is hidden by default even in full screen.
Hovering on the + shows a Add Todo dialog but hovering over any other icon does nothing. I had to click to see what the watch and stopwatch were. In general, I wasn't able to guess what any of the icons were, except for the labels icon. On the other hand, Github doesn't use icons: just a bunch of text which is imo nicer in terms of design and more user friendly.
GNOME is looking to self-host their own GitLab CE instance. We understand that GitLab.com might have some performance issues. This is specific to our hosted GitLab instance due to its scale. A self-hosted instance on a much smaller scale is much much faster.
Also, we're always looking to improve GitLab performance - check out issues labeled "performance" in the GitLab CE repo [1] as well as issues in the infrastructure repo which are about .com specifically [2]
* Commits visible on the main tab
A list of commits is just a click away in the MR view, in the "Commits" tab. Also commits that are added are also displayed in the main tab.
* Can see new stuff that happened
The main MR tab lists the actions that happened related to it in a chronological order, from first to last. You can always look at that and see any new MR changes
* Sidebar
The sidebar is expanded by default on larger screen sizes and collapsed on smaller ones to preserve screen real estate for the MR itself.
I opened an issue about the icons themselves, see [3]
* View rendered files in MR
We have renderers for all kinds of files. But in a MR, we diff the MD source files. If we rendered them, diffing them would be almost impossible.
I opened an issue about having toggle-able rendering in the changes tab in MRs. Feel free to chime in in [4]
* Review mode
Could you explain this in a bit more detail? Maybe we could open a feature proposal for this functionality.
Hopefully I addressed all your concerns, feel free to add anything or dive into any of the issues, or even contact me personally.
Finally someone sharing my opinion about it. I don't get all the hype they get especially on HN. Basically every experience I had with the product has been terrible so far. (And I gave it a lot of chances). I was keeping my thesis code on it and sometimes I go home and try to pull the work I have done in the lab and there's some error that I am facing. I moved my code to both bitbucket/GitHub and have been very satisfied.
I am not quite sure what pushed Gnome to such proposal or even considering it. But IMHO using anyone of two other providers would save much time for Gnome contributors.
They are clearly looking to self-host, which removes some of the issues of GitLab and gives it a massive cost benefit (not even sure if the enterprise products are even usable for public instances). EDIT: it's also the only open-source option of the 3, which per the linked document is important as well.
Sid will correct me if I am wrong but I think a big project like Gnome will want Enterprise because the last time I looked git hook was enterprise feature (hey they have to make money somewhere to keep the lights on)
Overall, I am very grateful that gitlab exists but gitlab.com does make me feel like gitlab over all is a slow piece of software.
The only Enterprise Edition feature that is under discussion is merging without creating a merge commit. We're considering to open source this to make this move work.
GitLab.com still feels slow but running an instance specifically for GNOME should be fast.
Yeah, it's interesting to see all the bad experiences mostly tie back to gitlab.com being shitty. I've run it self-hosted myself and have been extremely happy with it. Almost a totally set-and-forget experience too, assuming you don't care about those little updates all the time and keep it behind your firewall or reverse proxy.
Unless there's some special pricing, I don't see any of the enterprise options work out. You can't pay per month per contributor for a projects public bug tracker. So I'd think they'd stay with the CE and hack in/around the features they need.
> I don't get all the hype they get especially on HN.
I believe it all started when they got a bad rap for doing unspeakable things like supporting minorities to get into the industry, plus one actually wrong decision by a customer service rep approving a complaint about some word in some repository that could be offensive, but clearly wasn't in the context.
Next followed about a month of constant griping about how awful github is, followed by many many features being released which had been in the pipeline all along.
Meanwhile, everybody on HN was trying to find an alternative. Since going back to Sourceforge would have demonstrated slightly-to-obviously that Github was among the best things that ever happened to OSS, the heavy-hitters moved all their projects to Gitlab, which was a third-rate clone of Github at the time, and may or may not have advanced to second-rate since.
Those two projects are, apparently, really enjoying GL.
I suspect GitLab's customer niche right now is teams that want private/on-prem source control but aren't willing to pay for GitHub enterprise. If that is in fact the case, I don't think it's surprising that they're lagging behind their competition on features and UX, since the cost-conscious customer doesn't value those things as much. (Or, more likely, the person holding the purse strings is not the one suffering from those deficiencies.)
* compatibility with msys2. It's one of the best environments on Windows for building cross-platform apps (where cross-platform is Windows, OSX, and Linux). Ideally, I'd like to run a Windows VM for the CI build and have artifact uploads, all through the msys2 shell. I see a single rumbling here: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/...
Thank you for sharing your thoughts: you're totally right, this feature has much interest by the community and is an high priority. By the way, this is also a very complex topic, as you need to provide great flexibility but at the same time the best UX. As usual, we move by iterating on the issue by little steps: first of all we need the basic building blocks, on top of them we can create the final feature. I mostly agree that test results and other "custom" information must be extracted automatically from logs, but we need to provide a generic model that can be easily adapted to everyone. Iterations on that brought us code coverage information, artifacts for failed jobs and browsing and online display of artifacts (ready to be released in 9.2), and we provide also workarounds, like using GitLab Pages, that can solve some scenario until the work is completed. I'd like also to mention our current effort in supporting CodeClimate (https://gitlab.com/gitlab-org/gitlab-ce/issues/4044). We will continue on this path (one of the issues you mentioned has the "direction" label), always open in receiving feedback and promoting collaboration at any level.
Yes, but that does not diminish my potential explanation for why people sometimes do not wish to use github but gitlab instead, which is the subject of the thread (see title).
I absolutely second that. I moved from gitlab to gogs being tired of the gitlab setup mess, and it works so well. On the ci side I use drone and both products integrate perfectly
I really fanatically loathe Rube Goldberg machine software. "Once you've installed Postgres, MySQL, MongoDB, and Redis, make sure your Ruby version is newer than 2.0 and your NodeJS version is newer than..."
I definitely agree that GitLab is a very poor product. Upgrades every week and I get a 500 return, I mean I can't remember GitHub or Bitbucket having this sort of issue. Transferring my repos to GitLab is one of my bad decisions in my development life.
Sorry that you had a bad experience using GitLab.com. We’re working on improving stability and performance on GitLab.com. There's several ongoing efforts in improving stability and performance (Gitaly[1], Infrastructure issues[2], ...)
We always run the latest version of GitLab on GitLab.com and we’re working on making (almost) all our deploys downtime free (Issue: [3], MR: [4]).
Of course, you can opt to self-host GitLab. It’s easy and quick to setup and requires very little maintenance via our omnibus package [5], and of course, we're here to help you if you get stuck along the way.
Not sure. My experience with our Self-hosted GitLab instance has been quite great.
I only have some gripes in the UX/UI:
- On GitHub i find the layout / navigation pretty clear. It's a bit hard to explain this feeling, but the information is always well packaged and that makes it easier to grasp (whether we're talking about commit, issues, reviews and whatnot).
- GitLab has definitely improved (even though it's not that nice that you upgrade and everything moves) but still with their layout (probably using too much % of the screen?) i always am confused. I feel there's "too much information" on the screen and that makes it hard to understand where I am and what I am doing.
But I really really love GitLab Pipelines: we use it pretty much as it was intended (CI using Docker images on a runner, manual tasks for deployments, etc.). And it simplifies a LOT our devops.
I really appreciate your feedback, improving the UX/UI of GitLab is my number one priority. We have been doing extensive research on Navigation, you can see the issue here:
I would love for you to take a look and give us feedback on the two directions we are considering. When we made a significant change to our navigation by removing the sidebar, most felt that there was "too little" information being shown, so I am intrigued by your "too much" comment.
We use it internally at the company I work for. I wouldn't say it's a bad product, but I wouldn't say it's a good product either.
We've logged countless UX regression issues on their issue tracker and each one has taken 9 - 12 months to fix. Meanwhile, they keep churning out new features that we don't use.
I wish they'd just stop adding new features and spend 6 months fixing their UX and improving stability + performance.
> We've logged countless UX regression issues on their issue tracker and each one has taken 9 - 12 months to fix
Another data point: I've reported quite a number of issues, all of them have been triaged real quick, and many have been swiftly handled (the last couple were dealt with within a week). The longer ones are mainly larger scope (or depend on one thereof), or - wait for it - adding features.
> I wish they'd just stop adding new features
Every release brings a couple of features that we really enjoy having though, there's a balance to be had. BTW we're self-hosting and performance as well as reliability has been excellent. (disclaimer: happy EE customers).
Hi, i am sorry to hear your experience have been as it is thusfar. We are hard at work improving the product constantly. We though have to prioritise ;)
> You can't add comments on unchanged parts of the code in the diff-view.
> You can't see the what is changed in response to your comment between two MR uploads.
and
> You can't add comments when you view the diff between two uploads of an MR. My list of complaints is endless.
For the following issues I created these gitlab issues to start the conversation. Internally and on the issue there may be a reference to already existing issues covering these subjects.
Thanks for your feedback! You can always join the conversation and/or contribute in order to get things like this shipped faster!
It seems description on 32399 could be misleading. I didn't mean diff-between-two-comments, but in-response-to-a-comment. Gerrit enables this by showing comments in-line even when we view diff between two MR uploads.
On the left I see the old MR and my comments on that upload and on the right I see the new diff around the commented lines.
It's like that scene in Mean Girls when one of the girls desperately wants the expression "fetch" to become a thing but the other girls keep saying "Fetch isn't going to happen."
I feel that way about Gitlab -- so many people want Gitlab to replace Github, but I can't understand why. "Let's replace product A with product B because Y Combinator." I'm just not sold. If Gitlab were 10x better, then maybe I'd get it, but it's not.
Definitely not 10x better. But being open source and freely self-hostable give GitLab an edge over GitHub in two respects that are very important to some users.
This was the same with gitorious. Enterprises used their own gitorious servers, and waited for it to become better. Didn't happen.
Github always was miles ahead. Same now for Gitlab. Will not happen.
Frankly it might matter to some people that it is self-hosted and open source. But I myself for one don't give a single wit about it. I want something that works for me and that makes my life easier as a developer. I already have my development problems to solve and in no way I want to add problems of the party that hosts my code.It's just not worth it.
It's almost like we're in a free market economy where people can choose the best fit for them from multiple competing products. And then talk about benefits of them!
I can give you a reason. Github has decided it doesn't want to be a common carrier anymore, but instead act politically. This is unacceptable as a service.
I'll distinguish between their product (actually very good) and service (unreliable, slow). I consistently wish GitLab were as reliable and fast as GitHub, but I stick with them anyway because I think they are on the right path in business and product.
Thank you for the feedback regarding commenting on merge requests. The diff view is indeed very important for collaboration. In the upcoming 9.2 release (slated for May 22nd), we are adding the ability to comment on older versions of the code and diff between versions.
No you're not the only one :)
I quote 100% what you said. Also I think you don't hear much complaints simply because people quit GitLab once they try it and just move to GitHub instead (or something else for self hosting).
But having to stop working on the thing you're building in order to learn someone else's toolchain, build a fix and (and this is key) persuade another organization that a fix is valuable is incredibly expensive.
Not convinced GitLab is the solution, but I'm definitely convinced GitHub isn't.
Not as active in GNOME these days, so my vote is not really a vote... but I do have my own reservations about both "Git-Wrapped" solutions, especially if they start requiring pull requests.
Splinter/Bugzilla is definitely not a long-term code review solution though, so something really has to give there.
I don't really have many issues with bug management on GNOME (that pain really goes to the bigger multi-module maintainers and the reassigning of bugs to the right places in the stacks), but for code review I'd probably just replace Splinter with a standalone instance of Review Board and call it good enough for the time being - basically waiting for someone to come up with an integrated code review/issue tracker that isn't tied to their company's infrastructure (Hello Google), is standalone installable and manageable (sorry GitHub) and doesn't impose a pull model on patch pushers (goodbye GitLab).
if i had to pick something, i would at the least give phabricator a serious look to see how it stacked up against gitlab [https://www.phacility.com/phabricator/]
I submitted my first patch to Cairo a few weeks back and depressingly it was met with tumbleweed. I tried contacting people on irc but again, nothing.
In contrast I submitted my first patch to fontforge recently too (GitHub) - it was merged in a couple of hours.
Developer interaction matters and I know plenty of open source devs who have put in a lot of good work are going to hate me for saying this - but those old platforms you're using suck for fostering community contributions. (And I thought the code quality in Cairo was great - I bet if it was on GitHub there would be loads more activity)
> I submitted my first patch to Cairo a few weeks back and depressingly it was met with tumbleweed
There used to be a time (from what I've read) when free software meant a tarball available for download every n years. Apparently, Open Office under Sun was very good at not accepting patches at all.
Now, we have things like KDE Neon with git-unstable and git-stable which basically allow end users to participate in the latest changes in KDE and now the windows/meta/super key actually does something in KDE which I wouldn't know if I was on Kubuntu.
cairo is a hard dependency of GNOME, but it's not really a GNOME project, and it currently is pretty lacking in maintainership since Google hired up practically all of the maintainers to work on Skia/Chrome.
You might want to try shooting Bryce Harrington an email directly to see if he can review your patches. Good luck.
From what I recall, Skia's not an API stable library - it's seen more as an implementation detail of Chrome/Android - so adopting it as a Google outsider is... not easy.
This seems to be a pattern with Google/Chromium projects. NaCl for example is very cool and potentially broadly applicable as a sandboxing tech, but last I looked would be very difficult to untangle from Chromium, and all that work could be undone at any moment by a Chromium-internal change.
Seems to be used by Firefox. Seems to only have a C++ api.
Which might limit adaptation, although I suspect that most potential users might be using C++ anyway.
Edit: Servo has rust bindings for it, so they might also be using it.
Keep in mind that this proposal is for GNOME to run a GitLab instance themselves; not for them to use GitLab's SaaS product. AFAIK GNOME just avoids using SaaS generally.
Furthermore, the GNOME project will only consider the Community Edition (CE). This is good news because it actively helps push the boundary for what goes into the CE.
As an aside, are there any plans to improve the GNU rating of GitLab from a C to something higher[1]? While the LibreJS not working problem looks like a bug in how the licence files are tagged (shouldn't be too bad to fix), the way that licenses are presented and bad licensing practices promoted seems like a fairly easy UX thing to fix...
Interesting anecdote, KDE had the opposite conclusion and now uses Phabricator. They said enough was missing from Gitlab CE (ex: LDAP support) they couldn't drop in replace their current infrastructure with it.
> They said enough was missing from Gitlab CE (ex: LDAP support) they couldn't drop in replace their current infrastructure with it.
There must be more to this. GitLab CE does support LDAP authentication. It's been configured and operating on our corporate GitLab CE server for over a year.
Maybe they needed more advanced features like group membership sync? [0] For basic user authentication LDAP + GitLab CE works great.
They also offer Mattermost integration, which means you can authenticate to Mattermost using LDAP, which would otherwise be a paid feature. [1]
GNOME heavily investigated Phabricator as well. Including much work with multiple contributors using large Phab installations (such as FreeDesktop.org and Endless). All of this is publicly documented on the wiki.
I currently use a self hosted GitLab instance at work. I also have a collection of personal repositories on GitLab.com. I chose to put my personal work on GitLab.com because of free private repositories.
Over the last few weeks I've started to trial Phabricator, using the hosted Phacility.com service. I haven't actively migrated any code yet, but just using Phabricator to manage some workflow elements is a much enhanced experience. Phabricator's Maniphest (tasks, issues) and Project Workboards feel much more intuitive than GitLab's. The Kanban board on GitLab drives me insane with the amount of clicks I need to do things, small glitches with tags and lack of a single unified multi-project view. Perhaps I haven't used Phabricator enough yet to hit such little frustrations.
The point is, I'm probably going to migrate all my personal work over to Phacility.com and if things continue to move smoothly recommend using Phabricator at work, mostly for their workflow and project management tools.
I should make it clear that as a developer, I'm just messing about for my own interest. Professionally, I'm a project/product manager with a small team of developers and scientists. I wanted to try and standardise on a single tool to manage workflow, while still staying out of the developers' way while they did the important stuff of building the product.
Yeah, we use Phabricator since last September. Before that we tried GitLab EE trial for a month.
GitLab was ok but in retrospect the forking model with merge requests was cumbersome in our corporate environment. The way Phabricator works makes much more sense and the "arc" tool manages all the complex stuff like feature branch handling with automatic master rebase and branch deletion etc.
Phabricator has an excellent code review workflow... far superior to what GitLab offered back in September.
Sure, Phabricator internally uses patch sets and you have to install and use an additional tool "arc". But git without any additional tooling support just doesn't give you a nice code review experience IMHO. "arc" is filling the gap. And you have to know just two commands: "arc diff" to create a new code review or update an existing one and "arc land" do merge an accepted code review into master. The rest is vanilla git.
I highly suggest anyone to try Phabricator and its code review feature. Great, pragmatic open source software.
Glad to see GNOME supporting another OSS product, even if GitLab uses a hybrid OSS/proprietary model.
Don't understand the hate here for GitLab. It's a rapidly developing product, so yeah, it's got some rough edges. But my experience with it has been hugely positive, and I much prefer it over GitHub for a number of reasons. Integrated CI is a huge plus; for instance, I've set up a project that runs a static site generator after each merge to prod. This is certainly possible with other tools, but I'd rather have a one-stop shop. (This is why I also like Visual Studio Online, at least for professional work.)
Even if you're a die-hard GitHub fan, you have to acknowledge that some competition in this space is healthy. We don't need a repeat of the Sourceforge debacle. Centralization is dangerous.
Why has the entire conversation veered away from Gnome to everyone elses projects gone wrong on Gitlab?
I was hoping these comments could be about the benefits that could be had by gnome from enabling dev access through gitlab.
If you have issues with that one project you worked on with gitlab, please contact Gitlab and let them know, as they are very open and responsive and willing to work with you, but this is not the place to change the topic from gnome to complaining about that one project you worked on two years ago and why gitlab sucks even though you never took the effort to submit a ticket with gitlab to fix it
When Python moved from their own silo to github, the project instantly gained more visibility, with thousand of stars in a few days.
You see, github is not just a fantastic plateform, well crafted and reliable, to use git. The important part in the name is "hub".
Everybody is on github, have a github account, nows how to use it. It removes a lot of friction.
Now I know it's proprietary. And it's close source. But since their track record as a company is exemplary, and since you can easily backup the data in there anyway, not being on github is like refusing to put shoes for a marathon because your feet will breathe better.
The GNU project did an evaluation of code hosting providers recently[1]. GitHub got an F (and note that 'server code is free software' is only a requirement for an A grade). GitLab only got a C. There are more severe problems than just "is the server free software".
Also please note that neither GNU nor the FSF really care about new fads. Their main concern is software freedom, and much like the whole convenience-security tradeoff there is a freedom-convenience tradeoff too. The FSF and GNU project do not compromise on freedom.
> There are more severe problems than just "is the server free software".
Nonsense.
They have 2 reasons for it getting an F rating.
> 1. Important site functionality does not work without running nonfree JavaScript. (C0)
Contradicts what you say.
> 2. Specific information may not be available in all countries
Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments.
> see roskomnadzor[1]
This was blocked by the Russian .gov, nothing to do with GitHub
> and export controls[2] for more details.
They are a US company hosted with a US provider complying with US laws on exporting controlled data.
So to counter your point one issue is because they're using non free software, one reason is out of their control, and the other is following the law of the land they are doing business in. If this is a fail in the FSF then that's fine, claiming they have "more severe problems than not running free software" is disingenuous.
> Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments.
In the case of Roskomnadzor, GitHub is not under the jurisdiction of the Russian government---they made a choice to comply. They could have instead chosen to stand up to the Russian government, which would surely upset its citizens and the world and possibly lead to change. Possibly not. It's certainly a gamble.
rms drew a hard line on this. When I asked him about Roskomnadzor specifically, he was not moved. Quite the opposite, in fact.
I forget what he said about the export controls; I'll have to look at my mail archives tonight. But if they are complying with US law, and they have no choice, I don't think they'd be penalized in these criteria.
> > 1. Important site functionality does not work without running nonfree JavaScript. (C0)
> Contradicts what you say.
... no it doesn't. GitHub has server code and has JavaScript code that is sent to the client for the client to execute on the user's machine. This requirement is referring to the client code not the server code. The former is more of a matter of user freedom than the latter.
More importantly this requirement doesn't even require GitHub to make their JavaScript free, they just have to make their site work with JavaScript disabled.
I'm not sure how you could possibly read the requirement as saying "all server code that GitHub has must be free software"...
> Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments.
GitLab doesn't get a ding for this requirement, so clearly this statement may be true but it doesn't seem like you are required to act the way GitHub does by law.
> So to counter your point one issue is because they're using non free software, one reason is out of their control
They have written proprietary software and sell it. I admit that it's hard to fix this problem if you already have proprietary code (contractors retain copyright in some cases), but pretending like they were completely at the mercy of someone else is ridiculous.
You don't have to compromise, you just have to evaluate. What could go wrong ? In this case, the worst thing that can happen is that you have to get your data and move, which are both easy to do.
So what you can do is:
- create a git lab instance as a synchronized unused backup that doesn't require a lot of maintenance to work.
- use github as the main dev plateform.
- then if (and it's a biiiiiig if) something ever go wrong, you switch
The benefits are huge :
- much less work work for the GNU and FSF;
- much more reliable plateform. If you get hit by a massive traffic, your gitlab instance is less likely to hold than github;
- much more visibility;
- much less friction.
It's a win-win.
It's not about fad. It's about being practical. You can fight for your freedom without rejecting everything closed source. We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery labor in China. Which they all are.
Spend your energy wisely instead of living a dogma.
The GNU project would be promoting proprietary software by requiring free software developers to use proprietary software. As there exist free alternatives, such promotion would negatively impact the free software movement (people would say "why not use GitHub? GNU decided that it was okay!").
That is enough of a reason to discount proprietary services. It's that simple.
> much more visibility;
... for GitHub as well. Which is one of the main issues.
> We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery[sic] labor in China. Which they all are.
Non-sequitur. "X is bad, so why are you caring about Y (which is less bad)".
That's actually a much better reason that what's been used before.
As for non sequitur, it's not. There is no moral comparison, i'm just saying that practicality beats purity and that we all do it so advocating purity is defintly not credible.
> i'm just saying that practicality beats purity and that we all do it so advocating purity is definitely not credible
This is like arguing that a member of the Vegeterian Foundation should buy chicken rather than chick-peas because chicken is easier to cook. Or because the chick-peas are being produced using animal fertilizers.
There are many criteria by which you can evaluate software. Usability is one of them. Software freedom is another. The GNU project proritises the latter over the former.
More importantly it's got nothing to do with "purity". I really don't understand how people are surprised that the Free Software Foundation prioritises Free Software as a criteria over anything else.
This is only a moral/ethical evaluation done by the GNU project. It doesn't inform on the actual quality of the products. And of course Savannah would come first, since they're the one judging themselves according to ethical standards they decided themselves. Judge and jury with an after taste of self-interests.
> GitLab has been very receptive to many recommendations.
I never said it wasn't, I was just saying that the only meaningful blocker is on GitLab's side (though as you've mentioned in that thread there is some discussion on refining the requirements).
No reason apart from the fact that the ones judging are the ones setting up the rules for judgment and have a horse in the race.
And still, it doesn't get to the heart of the issue, we're not comparing ethical viewpoints here, we're asserting product quality from a user standpoint.
> No reason apart from the fact that the ones judging are the ones setting up the rules for judgment and have a horse in the race.
I don't know what you think the GNU project stands for, but I find it incredibly hard to believe that they would not give GitLab an A rating if they followed the requirements (which are publicly listed). As an example, they promote GNU/Linux distributions that are not funded by the FSF[1]. Same goes for the FSF's "Respects Your Freedom" mark -- they reward it to anyone who passes the requirements.
The GNU project regularly promotes non-GNU projects. This is all just FUD.
> we're not comparing ethical viewpoints here, we're asserting product quality from a user standpoint
That's what _you're_ discussing. One of the factors in GNOME's decision is the ethical concerns of the GNU project (since they are a member of the GNU project and ethical concerns are the main crux of the GNU project).
Wondering how they missed Kallithea (a software conservancy project) and RhodeCode in their evaluation. Everyone's mind is just clouded by GitHub/GitLab these days.
I disagree. Even their source-code on Enterprise edition is obfuscated a lot. For a company that preaches open-source they sure are doing everything to keep their own stuff as closed as possible.
Also, a lot of GNOME developers are strong on ethical side of open-source therefore they would never feel comfortable hosting something on closed platform.
GitLab is great choice because it's:
- Open Source
- Self Hosted
- Free (Unless you are going Enterprise)
Yes, the UI sucks and there was this database fiasco. However since it is open-source it is improving and adding new features 10x faster then GitHub.
> When Python moved from their own silo to github, the project instantly gained more visibility, with thousand of stars in a few days.
Think about that statement. One of the most popular programming languages in the world "gained more visibility" because a few thousand people / bots clicked a button.
Did (useful) contributions increase?
Did more people start using python because they could fork the core of the language, and have a stale copy of master in their account?
"the project instantly gained more visibility, with thousand of stars in a few days"
Not everyone has the same metric for success. Getting stars on a developer-only site doesn't seem to fit any of the gnome-desktop-project long term goals. Getting stars on a developer-only site seems at least a semi-useful goal for a programming language, at least in some sense.
You don't have to choose. It's git. It's decentralized. You can have your cake and eat it. Have most activity on github, but a dormant gitlab as a backup in the (improbable) case it reveals unsuitable. Github is not facebook, you can get easily all your data back, in a open format.
Except for issue/project tracking. And all ACL and organisation configuration. And CI hooks and so on. Of course GitLab lets you make a clone of this information, but that's a hack.
GitHub has REST and GraphQL APIs you can use to export that data. It would be great if there were more standards for issue tracking/code reviews that worked better across vendors, but GitHub is neither the best nor the worst in this regard.
I'd wait for the forking model to be fixed[1]. The current model can be really annoying when you have a large project where contributors are supposed to direct merge requests to deputies before merging with the main repository.
This is great. I dislike the Gnome project itself, but they have some subprojects like GIMP that would benefit from this. Props for not just moving to the most popular service cough, Python, but the one that is actually free software.
I don't know where all the hate for GitLab is coming from, but for my use case, their SaaS git solution is almost exactly what I have been looking for.
It's so good, I am both surprised and angry I didn't find it sooner.
I agree with a bunch of the UX issues raised, but a lot of the other problems are related to GitLab.com and if you self-host, it's a much, much better experience.
I've always wondered why they refuse to support Mercurial. I agree that git has won the race, but people still like and use hg. And it's always a win-win.
I have been using Mercurial for some years now and before that was on Git. Github used to be one of our remote repositories. The thing that Git excels is feature/bug-fix branches, which can literally be considered throw away branches. You work on one or more feature branches, independently and then submit a review request (github is just one option) and then have it merged against the actual release branch - all this without polluting the history of the release branch or without juggling with too many complex version control commands/tricks. Github wrapped around a lot of end user tooling around this concept (pull requests for example) and showed to the world how easy it is to accomplish this level of "parallel" feature work or bug fixing.
Coming to Mercurial, now that I have been using it for more than a couple of years, my experience is that, this workflow (which is now considered standard and well known through git and github) isn't possible to achieve. Mercurial's concept of branching doesn't fit into this scheme of things. They stamp each commit with a branch id and there's no way to erase that which effectively leads to a lot of issues if github has to support the model that I mentioned above - a model which is well known and popular at github. Mercurial recommends bookmarks for cases like these, which based on my experience and some of the discussions in mercurial dev list, doesn't work either. I hear they are working on a "evolve" plugin in Mercurial to sort out some of these issues. But overall, it's still very complex and requires a deep understanding of the mercurial concepts/commands to achieve what can be achieved in git pretty easily.
Given all this, I personally don't think it adds much value for github to support mercurial in such a way that the workflows remain (almost) the same irrespective of what underlying version control system you use.
RhodeCode already does this to perfection. They support mercurial, git and svn. I understand from the value point though! AFAIK, mercurial is being used in enterprise environment.
ahem, away from gitlab rants about projects unrelated to gnome, and back to gnome...
yes please
I actually spent most of last week working with Gnome edits.
One thing to note however. I use Fedora and the latest version moved away from X11 to using Wayland as a default (they can be switched).
Wayland is fine except its not viable for the gaming community. I am not a gamer, but I work with GPUs, so up until the past year with big moves from khronos to get GPU dev abstracted from just the gaming dev community, my dev dependencies are still tightly tied to the gaming community.
Theres also some things about Wayland that make it a bit premature in my opinion to be a Fedora default, though I appreciate Fedora being experimental in all of their releases.
To switch back to X11 from Wayland, which in my case was not for anything fancy GPU related, just to actually disable the touchscreen on my Asus UX303ub zenbook with a skylake processor. Wayland can't do that....
I had to downgrade gnome, and edit both wayland.conf and X11.conf files to switch X11 back as a default and then force disable the touchscreen.
This requires me to use an older version of gnome.
Why is this relevant? Because I'm not the only one right now retrograding gnome because of Wayland/X11 defaults. A huge majority of the PC gaming community operating outside of Windows OS is.
For me, in addition to doing all this, which only took a few hours to figure out, I had to reconfig releases of the gnome themes I use to get everything working. That being said, I'm obsessive about minimalist set ups and having a synchronized desktop/terminal tmux/vim setup for development, so I will spend 6 hours to get a tiny aspect working the way I want it to.
Right now, alot of experimental OSes using gnome are using different versions of gnome, so there might be overall less convergence on people using versus working on the latest gnome if it were moved to git.
That also being said, people who do that kind of thing are the people who will be deving on gnome, and it's what got me into UI linux dev in the first place.
That also being said, people in this world of gnome dev, are all using different versions of gnome.
That being said, it could help expediate convergence of gnome with upgrades to various Linux distros, as I know theres some mismatch between what I'm using with Fedora right now to have some basic default settings work.
However, I'm still in favour of moving it to git. I would love to have access to gnome dev that way.
> I'm obsessive about minimalist set ups and having a synchronized desktop/terminal tmux/vim setup for development
I think a lot of us here on HN are the same way. But if you want a minimalist desktop, why in the world run GNOME? In my experience, XFCE and LXDE are both at least as stable as GNOME and far more lightweight. Or you could go all in and run a tiling window manager like i3 or Awesome.
I use VIM almost exclusively except in some more applied settings for maybe specifically an app.. and tmux works really nicely with Vim. That's why everyone says "tmux and vim should just get married and get it over with already" as a quote all over the internet. It could be the case with the other two as well.
tmux also has a really easy way to create your own plugins, and tmux persist sessions for savings windows and setups through reboots.
Again, these were things I wanted and found tmux to offer, while working really well with unique vim setups I had integrated across multiple computers. I don't know if i3 or awesome has these same features, but I think tmux is a good setup and I don't see a need to switch especially with tmux persist.
I'd be happy to hear recommendations about i3 or awesome over tmux advantages. tmux is so great to me, so if you had some good examples of how i3 or awesome trump tmux then I would definitely listen and consider and look into switching more. I've never had an issue with tmux and have really really liked it, and found every aspect I need to be easily customizable through .confs and never had to work with a predecided set of options rendered through a gui type customization, which I always find limiting for me, rather than just knowing or learning what to type in the .conf file for sys configs and having it just work.
DESKTOP THEMES
I've only recently switched to gnome and used LXDE before and really liked it. I try to ride with Fedoras upgrades, and I know there were alot of opinions going around about having the default installs being switched to gnome, but I have not had any runtime issues with it.
That being said, I have a really powerful laptop, the one I'm running gnome on (other is a hackintosh but thats not by choice its for dev reasons), so I don't find anything I do on my laptop being compromised due to gnome, maybe my own bad code, but not gnome.
That being said, outside of initial testing of my skylake, I mostly run testing on centos on other systems and my main laptop currently running gnome, is an interface for which to run other setups I effectively use as servers or actual servers (and tmux persist sessions make it great to do that easily and save my entire detailed setup if i have to suddenly walk away from a detailed complex environment and not come back to it for two days and pick up where i left off, and that happens often considering I work simultaneously on multiple projects depending on my priorities for variable work schedules and more entrepreneurial endeavors.) so I don't find myself fighting over computing resources because of gnome.
I have not used gnome since I first tried ubuntu about 7 years ago, so I've had it for about 6 months before and not too many issues, only with integration for other unix setups, which is exactly why I think making dev on it more accessible or inviting to people (gitlab being a good venue for it aside, any venue) is a good option.
so far, I've been really happy with gnome since i came back to it. It took me about 3 hours to be set up and learning how to customize and make my own themes for it.
Gnome is not a bad desktop and it could benefit from more development by users who care about these things, minimalist setups and are constantly aware about runtimes and computational efficiency in every piece of code they write, which sadly...and somehow, many people missed day 1 of learning coding (big 0) and never seem to consider it until everything is breaking, and then say "hey lets throw this on AWS without exploiting the backend at all to optimize for the GPUs were paying for at the kernel level and assume AWS will figure out how to optimize our code at every layer instead"
at the low level, I've never done any custom mods on LXDE, so I can't sit here and pretend like I know some really good comparisons on computational efficiencies and design of LXDE versus gnome, but I think gnome is a fine interface, but could benefit alot still from more user dev.
Thanks for the reply and open to any other suggestions you have.
I still consider myself an amateur at everything computer/compsci related. I only minored in Compsci and code 30% of my time at work and then alot outside of work, but I'm not a top level dev by any means. I'm an Electrical Engineer (one of those I know) and code because I want to..not to mention due to the overlap.
So I'm always grateful to get feedback from people who spend more time exclusively working in this space than I do.
GNOME is part of the GNU project. If you think that the GNU project would use a proprietary product, you might want to have a refresh of what the GNU project stands for.
The fact that Linus used proprietary software to manage Linux was not seen positively by the community and eventually (after one of the developers tried to write a free client to interact with their proprietary service) everyone in the free software world got a reminder why we shouldn't promote or use proprietary services (the "gratis tier" access got revoked for the project).
The core idea here is great. I've often wanted to contribute to Gnome projects but have been more than slightly put off by having to learn their ecosystem of tooling/hosting on top of already having to learn how their projects are used together, built, etc.
Hosting on a git based system will lead to more people discovering and reading the code and ultimately contributing. This benefits everyone. Gnome has truly excellent projects and the more people work on them the better we have it.
However, this is one case where being a curmudgeon about being hosted on an open platform will shunt the possible growth of contributors.
The GNU project has already done a comparison of various repository projects[1]. GitHub and SourceForge both get an F, while GitLab gets a C (the lowest passing grade) with GNU Savannah getting an A (which is the second highest).
And, in keeping with the FSFs view on software freedom, the server code actually doesn't need to be free (though it is considered a negative and will prevent a service from getting an A rating). However they _do_ require that the site must be possible to use without any non-free JavaScript.
Here is the full set of criteria that GitHub fails to fulfil to get a C rating:
> Things that prevent GitHub from moving up to the next grade, C:
> * Important site functionality does not work without running nonfree JavaScript. (C0)
> * Specific information may not be available in all countries; see roskomnadzor and export controls for more details. (C2)
I don't get how a developer who's income directly depends on the code which they are writing or in general thinks that their project has value can be too cheap to pay a few little $ for an excellent, RELIABLE and FAST git source control, which without doubt is GitHub and certainly NOT GitLab.
I mean as a developer your code repositories are the single most important thing where you want to sleep well (and your production infrastructure). Rather save money on shitty cinema tickets, Starbucks milkshakes (the shit they produce cannot be called coffee) or save some money on some shitty Apple adapters, but please get yourself a GitHub subscription.
It's not clear if hosting your own Gitlab instance (they are not using Gitlab's servers, but their own) is cheaper than a Github's subscription. It's more a question about owning your own infrastructure rather than cutting costs. Also, as open source developers they probably are not comfortable with depending on a privative software.
That said, given the option I would rather use Phabricator (as I currently do).
> not comfortable with depending on a privative software
I am sick of hearing this argument. What does that even mean? How is the fact that GitHub doesn't publish their internal code making it's usage "uncomfortable"? Do you think that if they opt to use GitLab and GitLab goes down (and they will because they are shit) that they will adopt GitLab's source code afterwards to continue the project because they rely on it? No way... they will just move their git stuff to a different provider, done. So what's the worry about a private hoster? Git itself is open source which is probably what matters more.
GitHub has other ethical issues aside from the server code being proprietary.
However, you're missing the point. Using proprietary software for hosting means that contributors are forced to use the same software (thus giving up their freedom). Not to mention it would promote proprietary software over free software. Neither is acceptable for the GNU project.
Why are people surprised that the GNU project prioritises freedom over all other factors? That was sort of the whole point of the project in the first place, and compromising on that would mean that modern GNU/Linux wouldn't exist.
I think you are missing the point, because your argumentation about the GNU project doesn't really apply/make sense for not using GitHub. When an OSS project pays for GitHub it doesn't force contributors to pay for GitHub. Contributors are still free to do what they want. The only thing which they get forced to use it Git, which is open source itself and which is the same with any other Git provider. On GitLab they would be just as much forced to use Git. It is just as much as they would be forced to use the maintainers chosen programming language. So the whole point about GitHub not putting their source code open is really a moot point. It feels like that there's some people who are so religious about open source everywhere that they have become blind to the actual situation. Also not everything in the world can be free. If a software developer doesn't want to pay for GitHub, then what on earth deserves to be paid for. I mean why do I have to pay anything in the world, why don't musicians and actors just decide to devote their time to only produce free movies (equivalent of developers to only doing open source software) or why shall I pay for my food? Surely everything should be free and so should I only go to cooks who cook for me for free...
The GNU project did an evaluation of various code repository services, and GitHub has problems other than the server code being proprietary[1].
The problem is that GitHub's client code is also proprietary (namely their site does not function when proprietary JavaScript is blocked), which makes it a user freedom issue.
However, their server code being non-free is additionally problematic because it would mean that GNU was recommending the usage of a proprietary service when there are free software alternatives. Which goes against the mission of GNU.
> If a software developer doesn't want to pay for GitHub, then what on earth deserves to be paid for.
When I use the word "free" I am referring to software freedom, not price. Please re-read my previous comment with that context in mind.
Github should donate a license for Github Enterprise to gnome so that the gnome folks can have the best of both worlds - self hosted + github. Its a win for github to have a big project like gnome running on GHE.
Gnome already discounted Gitlab Enterprise as an option because its proprietary.
It is very hypocritical to promote free software while using proprietary software that you got special privilege for on the backend. KDE had the same line of thought when they chose Phabricator - if features like LDAP weren't locked behind Gitlab EE they would have used that, but they were only considering freedom respecting options, because they are communities of hackers that want access to improve their tools.
What kind of LDAP functionality did KDE want? LDAP login is in GitLab CE (open source) but LDAP group sync is in GitLab Enterprise Edition (proprietary).
GNOME is part of the GNU project, so the only "pressure" they could apply to GNOME is to make their enterprise offering entirely free software (at which point they will run it themselves because of GNUs and the FSFs position on Service-as-a-Software-Substitute[1]).
They upgrade every week. Who the hell does that to paying customers? And half of their website functionality doesn't work when they upgrade -- but their upgrade-banner always says "no down time is expected". It is a running joke in my company.
We constantly get error 500 during upgrades. Merge requests don't commit. Rebase feature didn't work till a few weeks back. Gitlab runners get stuck every now and then. I use it everyday because of company policy, but folks, Gitlab is a really poor product. Feels like they test their product on paying customers.
Also, do they even know how good their competition is at? You can't see the what is changed in response to your comment between two MR uploads. You can't add comments on unchanged parts of the code in the diff-view. You can't add comments when you view the diff between two uploads of an MR. My list of complaints is endless.