As I always say on every GitLab post on HN (and no I'm not paid to nor do I have any affiliation with the company) - we switched from a combination of Github + Gitolite/Gitosis to GitLab not long after it was release and my god it's damn good, It's really impressed us particularly in the last 12 months how rapidly they're developing the product and getting new released / fixed / features out. Especially like Gitlab CI w/ Docker.
I really liked Gitlab when last I tried it, but in the end I went with https://gogs.io/ instead. For a small-ish team this felt like the most straight forward self-hosted solution. Still missing LFS though, which sucks, but it's being worked on.
The native subversion and mercurial support for the same repos is incredibly attractive. Any idea how it converts them to a shared format in real-time?
I don't know how to feel about that, on the one hand it's "not using the soap you're selling" and makes you seem disingenuous about the quality of your product.
However, it is the "home of developers" right now, and they probably would prefer a low barrier to entry for people to get involved.
Many large (or aspiring) open-source projects seek to create a community of users around it, and having a lower barrier of entry to create such a community only helps the project. As you've said, GitHub provides such a low barrier.
I totally understand why people host open source projects on GitHub.com, most open source developers have accounts there so it lowers the barrier to contributing.
BTW If you host it on GitLab.com people can login with their GitHub account.
I wish GitLab could be a bit lighter weight as well. I'd love to spin up the cheapest VM instance I can find on a cloud provider, pull a Docker container, and have a working GitLab instance up and running, but they "strongly advise against" running GitLab at the amount of memory those cheap VMs usually come with (usually around 512MB) [1].
We did a comprehensive internal review of both gogs and gitlab. Gogs was a long way ahead of gitlab in terms of stability/speed and had pretty much all of the features developers tend to need.
gogs is pretty slow as soon as your repository gets bigger. At least when I last tested and contributed to it a few months ago. IIRC gogs parses the whole "last commit to this file or directory" before sending the response which is pretty slow.
Working for a 15-year old small software company, I converted a whole bunch of ancient CVS stuff (yeah, yeah, don't laugh unless you also have 15 years of profitability) to GitLab CE. After a couple of false starts it went flawlessly and now works flawlessly.
(I used the tigris.org migration tools).
The GitLab team is doing a great job. Thanks you guys.
The false starts in our conversion were mostly struggles with how to restructure our old CVS repos so they made sense in the world of git. A few of them had to do with capturing some oddball CVS specific revision and branching history.
None of the false starts were due to flaws or confusion in GitLab specifically.
I should, and if you pester me I will, sanitize our internal how-to documents and scripts and contribute them to the Gitlab community so the next guy can benefit from our experience.
It would be great to receive some contributions to our documentation. It has proven a big challenge to make sure it covers everything and stays up to date. We'd really appreciate it.
One of the most successful companies I worked at had no version control or unit tests whatsoever. The code was all maintained by one person (the company relied heavily on custom software internally but it wasn't their product), who was able to keep the codebase small enough to basically hold in his head the whole time despite generating millions of dollars of value.
That's certainly not how I would write code today, but it is amazing to see how much top-notch programmers vary.
In case you would like to shave a couple of seconds off per build, you might want to build a docker image with both luarocks and love already installed.
This would also be a great reason to test the awesome GitLab Docker Registry[1], which is also included in CE!
I was trying to look into Gitlab Runner the other day. How decoupled is it from Gitlab itself? Would I be able to somewhat easily write a completely different UI, with a different framework/language (say, Django), hook it all up to Github/Gogs and use Gitlab runner for the jobs themselves?
Because if that's what it is, that is pretty kickass.
The Runner interfaces with GitLab through a pretty simple API, so you could do that.
One caveat is that we might introduce a new API by releasing a new version of GitLab and GitLab Runner at the same time, then you would need to upgrade you project to stay compatible.
BTW To ensure nobody is confused, you can use GitLab Runner to test all kinds of projects on all kinds of hardware. We're discussing developing an alternative to GitLab but reusing GitLab Runner.
Im using Jenkins right now to basically handle docker deployments. Without taking the time to actually read up on it in depth, does GitLab CI handle ways for me to essentially just pull prebuilt images and run them on a targeted server with desired settings?
I'm already preparing to move to GitLab CI for images that I build myself (since Im already storing the Dockerfiles on gitlab)
That seems to be referring to using docker images as part of the build process.
Im referring to using docker images as the deliverable. I mostly want to just have a gui to do "docker pull x" "docker stop xcon && docker rm xcon" "docker run --name xcon -v /volumes/x/config:/var/www/config -p 8080:80 x" for me. There would technically be nothing to be stored in the gitlab repo here, except the config.
Replace the "docker pull x" step with docker build in the event that I'm using a dockerfile to build a custom image, which could trigger as a result of updating the dockerfile... but usually the dockerfile doesnt change, it just needs to be re-run to pull in upstream changes.
Thanks for clarifying. I'm pretty sure you can do everything you want here. You could install a runner on your production box and run those commands within a deploy job.
Well, unfortunately I don't have many contributors yet, so I can't speak much to the collaboration features. The only thing I can think of is that it would be nice if it were easier to get CI failures announced in Freenode channels. I haven't looked into it in a while, but last I checked it was a bit tricky to hook up push events into IRC.
All the minor complaints I had a while back have been addressed (not showing the readme as the splash page, and not being able to reply to issue emails) so I've been quite happy with it.
I also appreciate how force-pushes to master are disabled by default. The fact that my browser's Emacs key bindings don't get stolen by the issue textarea to do stupid markdown stuff is very much appreciated. (glares fiercely at github)
I highly recommend using Löve; the simplicity is very compelling.
I wrote a bit about testing on my blog, but it's more about the architecture of how the user-input system meshes with the internal reprogrammability. There's a bit about fuzz testing though: https://technomancy.us/180
Maybe I'll follow it up with a more detailed post specifically about automated testing in Löve since it seems to be not well-understood.
I was pretty impressed how easy it was for me (a server newb) to setup my own GitLab CI on a AWS server. For my projects now it takes around 15 seconds from when I push to GitLab for it to be deployed.
I love how responsive our local (departmental) instance of GitLab CE is -- it's downright snappy compared to the corporate instance of JIRA. We love the issue tracking subsystem of GitLab and use it as our main ticketing system.
This is the sort of result it makes us very happy to achieve:
"I have got by on minimum understanding of Git for a couple of years now--this really brought up my confidence in using Git. After I learned the Git internals, the esoteric commands really started falling into place."
--Nicholas Santucci, Monitoring and Performance Engineer
Wow. The power of HN. We did our webinar today and had attendees from the Netherlands, Germany, Serbia and the US. It was exciting to have an international audience.
Feature requests for Issues: priorities, and states other than open and closed. These are the biggest things keeping us from using GitLab issues rather than an external tool.
We need to be able to set priorities (ideally customizable, but at minimum high/med/low). We can kind of do that through labels, but it's messy because you can only search for one label at a time (no boolean combinations of labels).
Right now, when you assign an issue to a user, it's considered "in progress", and from there it can either be unassigned or closed. It would be nice to separate the state of the issue from the assigned user, since in our current workflow we assign many issues to a user, but that user might only be working on a few of them at a time. Using our current bug tracker, we can differentiate between "Open, unassigned", "Open, assigned", "Open, in progress", "Fixed", "Verified", "Closed", etc. I know having a completely customizable state diagram for issues is a big software task, but maybe there is some intermediary level of complexity that would allow better tracking of what is actually being worked on now vs. what is assigned to people.
We've done three physical events already. :-) I'll email you! Our next physical event will be teaching at Ohio Linux Fest (https://ohiolinux.org/olfi/)
I've moved from BitBucket to GitLab and on the whole it works well. I still use GitHub for open source projects though.
One problem is that a lot of things automatically work with BitBucket and GitHub but GitLab need manual setup. For example, TeamCity has out-of-the-box support for both BitBucket and GitHub but you have to set up GitLab as a raw git repository (and create a user for it etc.).
edit: I should add that I've also used GitHub professionally with private repositories. However, I quite like having separate credentials for open source vs. more sensitive work.
Is there anything we can do from our side? We're very interested in making it easier to integrate with GitLab, but also happy to invest some time into making existing integrations easier to set up.
Our hope is that with time, it'll become obvious that when developing an application, you integrate with GitLab as well as with BB and GH.
Since I have your attention, something else that I think should be on your radar is creating/defining supported injection points in GitLab's UI. If you haven't done so, you should look at what Microsoft has done with Visual Studio Team Services.
By providing supported injection points in GitLab's UI, GitLab will be able to signal to others, that they are a solution you can safely build on top of.
Right now, to integrate deeply, you'd have to go through the heavy-handed process of creating a service [0]. That then does allow you to do almost anything, but the barrier to entry for that is high.
I created an issue for your proposal and hope you can provide some more feedback on how this would work, ideally [1].
I'm constantly impressed by how involved GitLab engineers are not just on HN but other communities when brought up. Not sure if you guys have people constantly looking for mention of "GitLab" but even if you are, the responsiveness and agreeableness to look into issues and invite people to be a part of the solution they seek out are phenomenal habits and I applaud you guys for it. It's one of the many reasons I converted a while back from Github and probably wont be looking back anytime soon.
This is great to hear and I personally think this the next battle front for gaining/retaining Git users in Enterprise. I'm currently working on integrating with Bitbucket and Microsoft, and I'll comment on the issue in a few weeks and provide some feedback.
Maybe create a plugin for Visual Studio, like GitHub does. Also try to work with JetBrains to make their GitHub plugin work with GitLab?
The GitHub plugin is available during installation, both with Visual Studio and JetBrains products, which makes it much more convenient to use. Things like creating a gist from code in IntelliJ or PyCharm also work out of the box with github.
We're exploring the VisualStudio option but as Job said we currently don't have the knowledge to make that happen. I've logged an issue for this request https://gitlab.com/gitlab-org/gitlab-ce/issues/20686 you can back it and follow it there.
As for JetBrains, we discussed this option with them - it would help if you create an issue for that on their platform as a user request to surface it. The more demand their users will have for this request the more likely it is to happen.
I have this problem too. It's not hard to set up, there are just so many tiny pieces that need to be run by hand that it's going to take a human well over an hour to read through the docs and get it right.
Someone made a Saltstack state[1] that I've used and had some success with - installing and configuring Salt from zero and using this config is still faster than installing Phabricator by hand.
Gitlab is unfortunately a pig, in the large and bloated sense of the term. Which is really sad! I love the app, it looks better than Phabricator and does so much more, but then I can throw Phabricator on the same droplet I use for plenty of other stuff with resources to spare for $5/month, where Gitlab would require a dedicated $10 instance just due to memory usage alone.
Have not used them, but I really appreciate how their copy is written to appeal to devs. Ex:
Customizable Task Management
Plan features, track bugs, and award tokens. Maniphest lets you customize input forms, use custom fields, and has a rich API.
Keeps track of lots of bugs.
You can assign them to people.
Maybe you could fix them, eventually. (optional)
Build unique task forms for every department.
For example, look at this feature in Phabricator itself: T6526
-
Business Rules
As your company scales, keep track of activity with Herald, which notifies you when things you care about happen (like a specific file being changed).
Write business rules.
Everyone loves business rules.
Keep an eye on suspicious new hires.
Warns you about plotting and scheming.
Build triggers on tasks, commits, revisions, and more.
If only phab didn't insist on squashing a patchset into a phabricator-commit, losing the carefully created history of a branch. Cumulative mega-patches are of little use when bisecting or trying to understand how a change works by being able to follow the steps to reach the final diff. A good commit history with separate commit messages explaining the diffs goes much further in allowing someone else to understand a change than any code comment could. This is also why merge commits are useful, because they allow you to group the commits for a feature branch and not miss any of the commits involved.
Phabricator could easily include their metadata in a merge commit, instead of collapsing the branch into one mega-commit. I know some people love a flat history without merge commits, but those lose a lot of info available with a graph/tree visible when there are no forward merges.
Thanks for the link. As arcanist is the php-based client to speak to Phab, does this mean it's a user setting only and is fully respected by Phab, meaning it's something set on first publishing of a diff and kept in that setting? Is this also possible when submitting a diff via the web interface?
What's funny is that mutability didn't exist for Mercurial support because when it was written Mercurial had no official mutability feature.
And I can only suppose mutability being default for git support is because of Facebook's dev style. It's wrong to assume that those who want merge commits for the final merge onto master do not rebase locally before sending a pull request. Rebase is a standard tool for working on your branch (aka patch set aka patch queue) and it's normal to rewrite it upon each revision of the branch sent for review. Does phab support multiple revisions of a branch in one diff or does it require separate diff tickets? This is something that Gerrit got right, allowing one to see the diff between revisions of a branch (patchset).
I posted before[0] about why I moved to gitlab; I'm using a self-hosted instance and the only real complaint I have is resource consumption. But if you bite the bullet a bit it's a really great product.
The other thing would be "ease of deployment" or lack thereof- if you're going for anything other than omnibus installs or docker images then it can be a bit painful. (I wanted to run on freebsd for example).
But, yes, it's super nice to have something not only comparable to github but even superior in some areas. I would definitely run the enterprise edition if that were my decision at work.
How has your experience of installing gitlab on freebsd been?
Anything in particular that can be improved?
I'm pretty sure the gitlab team is open for all kind of improvements. :)
Someone wrote a very nice and detailed guide, however upgrading isn't mentioned[0]
it also suggests operating under bad practices like running gitlab from /home/
I guess I could write a decent salt-formula to do all this, but I can't handle upgrading of gitlab easily, it always breaks when I take a new branch from git and run a gitlab-ctl reconfigure.
Last time I tried Gitlab, I changed the setting to allow more than 10 projects for each user but the changes never took place. So I stuck with Gogs which is much much faster anyway.
Similar view for myself; though the resource consumption is such a minor complaint that I don't even really consider it relative to all of the benefits GitLab provides.
I feel as though some of the recent UI changes were cosmetic and degraded the experience. I was especially unhappy about the sidebar being pushed into a hamburger menu (which can be pinned open, mind you).
I'd really like for UI updates in the future not to be jarring and seemingly pointless. I really liked the UI right before the overhaul, only minor tweaks seemed truly necessary. Many of the tweaks I would have suggested before have come through; such as putting profile information and notifications in the upper right hand corner. I'm glad about that.
Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
Thanks for your feedback - we are always working on improving the UX/UI and appreciate your input! I know that large changes can feel jarring at first but we hope that in the end, they help improve workflow and productivity.
The sidebar is a global navigation and not always necessary when interacting with page-specific content on the site. GitLab is very content heavy and by allowing the sidebar to be collapsed, it allows users to have more space on smaller screens to read/scan the information that they need. As you mentioned, the sidebar can be pinned so users can view the navigation all the time if they prefer, esp if they are using a larger screen.
If you have other examples of changes that you felt were pointless, I'd love to find out the reason for the change for you!
I've asked some people that work on our UI to respond, but we're aware that we have some ways to go before it's really good and that the large changes that we're making can be painful at first.
> Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
Could you elaborate on what kind of features we'd be required to add given your suggestion? What do we miss?
I just finished an evaluation of Gitlab for our company and I'm blown away by all the awesome little touches that are geared toward productivity (merge requests that can be merged to a second branch with two clicks? yes please!).
That said, I'm holding off for now because I'd love for it to replace both Github and our current ticketing system, and rather than doing two migrations, I'd rather wait a few months until you guys have fleshed that out and do it all at once. The issue boards on your roadmap look absolutely fantastic, but the true killer feature I'm waiting on is time tracking, which I'm hoping makes it in later this year. Get that in and I think you'll see people flock to Gitlab.
Was over a year since I last used GitLab, and I wonder if the resource usage and response times of a self-hosted instance has improved? Back then we were 3 developers having roughly 20 repos. The memory usage was over 2GB when idle and response times were at best between 2-3 seconds.
Testing your hosted version, loading this page[1] for example takes 4 seconds (3.6s TTFB). Don't get me wrong, the platform and its features are very broad and very good, but I personally can't stand having such long loading times. It's very frustrating because I really want to use GitLab and its features.
My feedback would be to set a main focus on reducing the TTFB for the Web UI, but also the Git server, because it takes a couple of seconds for it to respond to pushes.
I get 5.5s now when I re-run it (probably due to caching). We've been working incredibly hard to make it faster, we have to use it everyday, so we know exactly how annoying the lack of speed can be.
We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application!
Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository).
If you run your own instance of GitLab now, it will be fast. Since last year March we've grown from 9 to now 100 people, many of which dedicated to performance.
GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0].
Why do you offer hosted EE gitlab free? I mean I love it but that seems to run counter to keeping gitlab around. In fact there seems to be no way at all to pay for gitlab, without having to host a local install.
Why doesn't LFS support SSH authentication? It has been requested numerous times and has missed numerous milestones. I'm still not convinced it will hit 8.11. We desperately need LFS support, but we use one time tokens, so LFS Authentication over HTTPS just won't work for us. We are an EE customer and this future is way more useful than a UI redesign! https://gitlab.com/gitlab-org/gitlab-ce/issues/3589
Git-LFS is a github project, you'd be better off asking them. But yeah I share your exp. without SSH and with all its numerous bugs LFS is one of the worst pieces of software i've come across. We switched to using rsync for binaries/ large files etc.
We're planning to do this as soon as possible. I agree that it has taken a long time. We simply did not have the capacity with the people that are able to work on this, to build it earlier.
We now have strengthened the team that works on these issues. I'm seeing whether it's possible to ship this with 8.12 (due Sept 22nd).
Just to give you guys some credit: I've had the pleasure of working with RhodeCode on my previous job 2.5 years ago and it was an awesome experience. HG & Git support, full-text search, repo-specific access control, a nice gui, easy setup, etc. Unfortunately, most devs and sysadmins I talk to don't even know about your product, which is a real pity, as they all use the same inferior products and don't know what they are missing out on. Now i'm stuck with gitlab and bitbucket-server, which everyone thinks are great, but every time I log into them I silently cry out for rhodecode. Hope you guys are doing well.
@dvdgsng We're better than ever, thanks! I don't know if you heard, RhodeCode CE is now free and open source. Feel free to join our Slack: https://rhodecode.com/join
We'll be rolling out a major release next week, might be the right time to spread a word to colleagues ;)
We hope to ship Issue boards[1] this months, which will be a mayor improvement! But maybe you could be more specific to what you're missing? We'd love to hear your feedback!
Issue boards is great, but this is far from what we would need, tbh. We need a bugtracker, not a scrum board.
Mostly, we need a way to defined custom fields to be able to triage, query and reassign automatically. Like for example components or platform. And labels are clearly not enough for that.
We do recommend you allocate resources generously, with 2Gb minimum.
That said, there are ways to tweak it. I believe you can reduce the default amount of Unicorn workers to one, as a start. Further than that I'm out of my league; I'll ask one of our awesome service engineers to respond here.
We are in the middle of migrating from Bitbucket to our self hosted CE version and apart from a few permissions issues on SSH keys we have had no issues with the whole process and updating our deployment system was just a case of changing git urls.
The idea of switching from one company that holds your data to another doesn't make sense to me. What does make sense and is worth working for is being able to host my own code on my network. That's where GitLab really comes in for my work. I have no reason to switch from one platform to another if I can't host it in my own network.
GitLab was a great idea but from my experience it's been built on an extremely frustrating method of deployment.
I'm not a dev ops person nor do I want to be. I want things to be as simple as "run this and it will work" without me needing to do much of anything.
I tried to setup a GitLabs instance but after running a simple update command (apt-get update && apt-get upgrade) it broke. It seemed to have something to do with something called Sidekick at the time or something along those lines. It was just frustrating that the automated update scripts from their deb BROKE their own system. That just should never be a possibility in a system, I have near no tolerance for dealing with crap like that.
After messing around with it for a while I gave up and tried Gogs. It was easier to use but using go's build tools yielded similar problem for me. It's not the easiest thing to setup and takes a bit of know how to get Gogs and golang's build tools working (I know someone is going to tell me I'm wrong and that this did not happen to me).
I settled on GitBucket [1] and I have to say I'll not be switching to anything else. It was simple: download and run a single jar file. I setup an unprivileged user, it's own opt folder, and a small init.d script to do everything I needed. To update I download the latest version and I do a drop in replacement with the .jar. Nothing difficult. (Sadly GitHub seems to have put legal pressure on them to change their 'look' so they've done that but before that it was perfectly stable in appearance unlike GitLabs).
If anyone is interested in the self-hosting aspect of this, I'd say don't look at GitLabs, Gogs, or any of the other systems out there. Look at GitBucket.
I'm surprised you're not running the docker instance, it's literally "run this and it will work" in fact, most of their instructions are rather on the nose.
Getting docker working for me has always been a pain. I've still not gotten as docker install working across updates or dist-upgrades.
Again, I'm as much of a sysadmin/debops is a neurologist in the way that I'm in no way a neurologist. If I cut open someones head, maybe messed around with some things, and closed it up they might be ok. That's how my servers 'run'.
Anything outside securing the system (ssh key auth, non-root user, etc) to a standard good enough for me is not doable.
We moved from BitBucket on premise to GitLab CE on premise.
Actually most things now just works.
Updating is a breeze.
Instead of downloading a installer and copying / fixing server.xml we can just do a apt update && apt upgrade -y.
Some things are a little bit akward but BitBucket didn't had this, too:
- FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)
- Artifacts API is limited to everything or nothing
- CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
- No Custom CSS (yeah our logo isn't 72px x 72px...)
But then again BitBucket didn't had these things anyway so except the bug it's nothing that would've hold us back.
Everytime you wanted a Feature for BitBucket, the guys said that there is/was an extension. How dare that costed a shitload of money which would even superseeded GitLab EE.
> - CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines
Do you have more examples of workflows we are not supporting at all or well enough?
> - Artifacts API is limited to everything or nothing
Right you are, you might want to track this issue[1].
> - CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
I don't fully comprehend what you mean, could you elaborate?
Not supported Workflows:
- JUnit XML or similar output reading to have a nice output what's broken / worked
- Checkstyle output / pylint / tools for other languages
- What I said about Artifacts
- Artifacts are hard to Track I already wrote into [1] which would also be a good way
- Actually external Triggers can't be conditional:
And I guess these are the things my company does / did with jenkins.
There is also another downside but we don't do that anymore:
You can't push from CI to master branches, some people do tag and create builds with their CI / CD (which we also did) but now we just push a Tag to the Repo and the CI will be: '- only: tags' and catch that up.
That's all stuff I can think of now which is probably not supported by most "simple" CI / CD Tools. I guess only the big one's have such a thing like TeamCity, Jenkins and Bamboo.
Thank you for the awesome detailed feedback. Responded point by point below:
> FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)
These are always hard choices to make for us. We wrote about these decisions here [0].
> CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines
We're still young, but confident that we'll get there! CI/CD is a major focus for us and we're working really hard to improve it with every release. Love to get specific feature requests for things that we miss in comparison with Jenkins.
Regarding the bug: I've pinged our PM on it.
> Artifacts API is limited to everything or nothing
Could you elaborate? I know we have numerous improvements planned, but I'm not sure about their prioritization.
> CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
Hm, could you write a feature proposal for this [1]? It sounds like a great improvement.
> No Custom CSS (yeah our logo isn't 72px x 72px...)
We're extremely hesitant to do this, as we make many changes between releases. This would break custom css with every upgrade, in turn resulting in a worse experience.
I rather hear suggestions about specific parts in the interface that should be made customizable or suggestions about changes to the UI altogether.
Although I'm not a fan of custom css, there is an issue to discuss this and I welcome your input there [2].
Actually as already said even with the stuff mentioned here, it's really really a good project and we are happy.
to [0] we've gone the CE route first since we are too small and too fast running that a EE makes sense yet (too good that you can switch between the two without any major drawbacks [http://docs.gitlab.com/ee/downgrade_ee_to_ce/README.html] and [http://docs.gitlab.com/omnibus/update/README.html#from-commu...] thats one of the major selling points, ease of use is really big in gitlab). but sitll every feature mentioned here wasn't in bitbucket so it's not like we've missing something, we've gained something while switching so we are probably whining on a really high level ;)
Oh and thanks god for the easy backup stuff, which even works while running (which other products doesn't....)
I'm working on a proper Docker setup for GitLab development which I think can be made production-ready pretty easily after the development version works.
It's hard separating the different moving parts (gitlab, gitlab-workhorse, gitlab-shell+ssh, postgres/mysql, redis) but I think I will have a merge request ready soon enough :D
Not right now. I'm following the install from source guide so it'll be as close as possible to production. I'll change some things the omnibus package does better, then apply the GDK stuff so people could use it for development.
I have some code. I guess I can submit a merge request + issue on gitlab-ce and gitlab-workhorse, but I need to read CONTRIBUTING and PROCESS first :P
Gitlab is pretty awesome, especially because they let you have unlimited private repositories on their website. So far my biggest annoyance is that when you click on a project you don't get a list of files (like you do on github) but just the projects readme, and even then only if you remembered to capitalize it.
How about costs compared to Bitbucket? I appreciate what you guys are doing but I think Github is cashing in on their brand and for a while they had the best UX (they still might! but I no longer care anymore as all the competitors are "good enough" for me) which lets them set a high premium people will pay. However, I think it's unfair to leave out Bitbucket, they have come a long way.
The first example of 8 developers and 20 repos is $10/month
or 100 developers and 300 repos examples is $100/month
What is the cost and/or time involved in maintaining DigitalOcean (or whatever VPS)? Security updates, upgrades, redundancy/availability, backups, or when something goes wrong the time involved in debugging/fixing (github/bitbucket have had their problems, is gitlab 100% available w/o hiccups)?
Very little time, in my experience. unattended-upgrades takes care of most security updates, a gitlab update is just "aptitude update && aptitude install gitlab-ce", and it automatically handles offsite backups.
If availability, security, backups etc. are highly critical for you and you don't want to host yourself, you could also have a look at our GitLab hosting service called GitHost (https://githost.io). It gives you your own private and secure GitLab instance on DigitalOcean which is completely maintained by us.
I tried their free tier and it was just extremely slow. A small project where commits usually took 5 seconds now needed >1min for any operation.
Moved it all into the google cloud and it works at the speed of the network. But we don't really need any of the features except the git repository anyway.
Free tier as in self-hosted GitLab CE or GitLab.com?
Self-hosted might be slow if you don't have enough RAM on the system you're running it with, but as long as you have more than 2GB it definitely shouldn't take more than 1 minute for a basic operation.
As for GitLab.com, that can be slow (we're working on improving it, much better now than it was last year, but still progress to be made!), but it should never take more than a minute, otherwise it'd just timeout. When did you try it out?
You'll be very happy to hear about Todos[1] then! You can add a todo or mark it as done from the sidebar on any issue or merge request. It'll stay in your Todo list until you mark it as done or comment on the issue/MR.
FWIW, I recently transferred my side project from bitbucket to gitlab and I'm really happy with it. The issue tracker is significantly better, and the built in CI seems great but I haven't started using it yet since I already have codeship going.
I did the same last month and then transferred back to bitbucket.
The response time on gitlab.com was painfully slow. That extra 2-3 seconds waits for each commit was enough to drive me back. I still use github for professional projects and bitbucket for personal ones.
I had the same experience. The other thing I would add is that the social side of Gitlab is not as refined as GitHub's. There's no "timeline," for example.
On the other hand, gitlab's "network" view of commit branches is excellent and I've never been able to find anything remotely similar on Github. Essential to manage development in multiple concurrent branches.
It's similar, but gitlab's graph has a much more readable and sensible 2d layout. The way tig and gitk line up/layout the branches is often very confusing. Gitlab makes it much clearer where the branch lines go, while tig/gitk seem to left-align everything as much as possible, making the lines twist and turn and difficult to trace.
I've run Gitlab for about a year now and I think it's great.
However it is sluggish on a 1GB box and I think you need at least 2GB. Since Linode doubled the RAM on their $10 boxes then you can get it for the same price.
My gitlab-ce instance runs on a vm on an internal hypervisor machine. I just upped the RAM provisioning from 2gb to 4gb, and now it's plenty fast.
One of the benefits of working for a software company that started in the pre-cloud era is a surplus of server boxes, now retrieved from colo racks. :-)
If your concern is cost, bitbucket always have free private repositories.
If your looking for privacy and protect your sacred code, install gitlab on one of your server or vps.
Thats what we do at SAIT
Fair point, but it's important not to fool ourselves in terms of data safety or at least specify what we mean when we say "it's private on your vps".
If your code is private and not meant to fall into external hands, then putting it on a VPS won't protect it. The only way is to put it on a machine that's only used from workstations that access it in a local-only fashion, inside containers/vms that have no way to contact the outside world. This means the build process may not access the internet and has to rely on a cache of external libs if needed and allowed. This also implies that network config won't allow access as forbidden via VLANs or similar measures.
If someone wants to steal your code, grabbing it from your vps won't be harder than doing the same on github/gitlab because the procedures to get access will be very similar.
I suspect by private code you mean code which shouldn't be publicly clone'able but isn't behind locked doors otherwise.
I recently moved my personal project from GitHub to GitLab and the whole process took me less than a minute, with a simple git remote set-url on the client side.
The future is amazing.
Not wanting to diminish what GitLab is doing, but what you mention is an inherent characteristic of git itself that applies the same way to GitHub, Bitbucket and a self hosted git bare repository. Any git host should expose a git interface for it to work as a git repository.
Yes, but they simplified it a lot. I just connected to github, chose the repository and clicked import. Maybe all of those services have it that way, but I'm just glad that GitLab had it.
That is a different case than configuring a different remote on config and pushing to another host which is what I interpreted reading your comment, my bad.
Out of curiosity, does the import process include all issues, PR and comments?
Sure!
The only reason I wasn't using GitLab before is that I had a writer working remotely on my game and I didn't know how to explain to her how to use it. So I had moved everything to GitHub and told her to use their desktop app, which makes the clone/commit/push/pull flow amazingly simple.
I login to my server once a week and run a yum update. Backups are scheduled, so I don't have to concern myself with that.
No troubleshooting. But we're a small (<10 developers across 4 repos with access granted to ~ 30 people to GitLab for ticketing) team. Even my non-technical people are able to use GitLab for ticketing without bugging me, so that's fantastic.
Spent 30m installing it and configuring SSL. Nowadays I spend a couple of minutes monthly doing "aptitude update && aptitude install gitlab-ce" (after 5-15m reading about the new release, to see if it's worth it / problem free). We never had an issue with the auto-upgrade.
It comes with support for automatic offsite backups (we use S3), so besides occasionally restoring to make sure they're working, that takes no time at all.
If you don't want to maintain GitLab, either CE or EE, but would like to use it, you might want to take a look at GitHost.io
The instance I maintain takes me about 15 minutes a month. Security updates are done automatically so all I've got left to do it 'apt-get install gitlab-ce' once or twice a month and thats it!
I'm using paid GitLab hosting via the GitLab-owned GitHost.io, so zero: everytime an update comes out I get two e-mails and that's it.
The pricing is extremely competitive. We are a small shop so the smallest package ($35, recommended for up to 30 active users) is good enough. We started with a self-hosted GitLab via docker and switched to GitHost as soon as it was bought by GitLab.
Like 5 min install it, ~30 min configure it, then about every two weeks spend 5~10 min check any new release and release notes, then just "docker-compose pull && docker-compose up -d" to upgrade.
GitLab is great and it's lovely to see a diverse selection of tools, but I'm not too convinced of the cost benefits – for a team with 100 developers, the annual cost of ~$11,000 is a pretty small amount compared to the maybe $25m salaries you'll be paying!
Well where I live, the final salary you get in your pocket is about 60% of what the employer has to pay (the rest are taxes and "social charges" which include medical insurance and retirement funds). If it's the same where OP lives, then he was probably thinking about 125k salarys + taxes, charges, etc.
Also, he must be considering other expenses that come with having employees (though he did say "25m in salaries").
Still, if you bring the salaries to 100k a year, it still compares favorably to GitLab: $11k vs 10M.
You of course realize that "salary seen by the employee" is not at all the same as "costs payed by the employer". (For example, social security and health insurance).
Sorry, that was my point – Github is ~ $11k for a team of 100 developers. The difference between '$11k' and 'free' is basically irrelevant when you are paying > $25m for your engineering team in the first place!
What is the benefit of moving to Gitlab from Bitbucket (or Github) for private repos?
Same feature set, Gitlab cost more per user and on top of all you have to run your own server? Am I missing something here?
I'll leave the marketing talk to less biased people here, but do note that:
- you can use GitLab.com for free: unlimited public and private repositories, unlimited collaborators, free hosting of your Docker images, free hosting of your static site with any static site generator and free CI / CD
- GitLab CE is fully open source (MIT Expat). You can easily install it anywhere you want.
It seems like that is the main selling point. However, I think that most of us don't want the extra weight of managing yet another tool. Thus why many of us use GitHub to begin with and not something else...
My big concern when I see a company that gives away too much for free is that they are probably unprofitable and will at some point:
a) Start charging for things that I'm used to having for free
and/or
b) Go bankrupt/get bought out by a company and disappear
Do you really sell enough enterprise licenses to give all the rest of this stuff away? From a look at your site, that's the only source of profit for your company that I can find.
You mentioned Mac runners, and if this includes iOS you'll make a killing. Figure out how to interact with a fast Android emulator and you'll be able to pull in a decent chunk of agencies that don't want to buy in house build machines.
You can use GitLab.com with no charge. It's free in the same sense as GitHub is free, except it also runs on open source software (well, GitLab EE, which is a superset of CE and has a proprietary license but is still developed and supported in the open unlike GitHub).
AFAICT the "cost" is that you're effectively load-testing GitLab EE and help guiding the development of a commercial product. Plus you're giving GitLab free marketing. But to the extent that anything in life can be considered "free" (as in "gratis"), GitLab.com can be used for free.
We're thinking about charging for specific GitLab Runners in the future (think Mac Runners) or additional storage (we have a soft cap of 10GB per repo).
We are a company of 10 on GitLab CE (We selfhost via the Cloudron). Costs us ~60 a month, so it's already cheap for us. We also have a bunch of other apps on it which saves us more money.
I would like to see that there is just one gitlab version, and that the enterprise features are simply available in the community edition too. I will not pay just for a feature like repo mirroring, but it's i think a feature many people will use and or utilise when moving, migrating to a gitlab setup.
But it is the one and only feature i am missing so not worth upgrading to EE for me.
As soon as an alternative (open source, self hosted, free) comes around that does have this built-in, i will be tempted to try it. (and of course on success i will move away from gitlab).
But for now, gitlab (CE) works best for me, self hosted.
If you think about what you're asking: youre asking for folks who build infrastructure you rely on to have no viable way of creating a self sustaining business model. Aka no virtuous circle. No development. This perspective is a classic tragedy of the commons situation and makes perfect sense for you to have as an individual. But it's sad.
There will always be users like me who know how to self host stuff and don't want 3rd parties having access to their repos. But there will always be plenty of people who like to outsource this, have it hosted by 3rd party etc etc. It's the service that is worth the money, not the features.
Features have a limited value, they are valuable until an alternative provides it for free (which is the common thing these days). And that will happen here too, just take times. Same as gitlab nibbled at github, something else will come around to take share from gitlab.
Simplifying the development to just one tree/version, saves a lot of maintenance, development discussions, allows feedbacks of all features by self hosting users as if they were enterprise hosted clients. This also has a value.
I wasn't refering to hosted vs not hosted. I was referring to the virtuous cycle of supporting people by giving them a viable business option who make software (whether FoSS and deployed on local infrastructure or hosted).
Do you believe Linus Torvalds deserves to have a salary? Are you happy he does? I sure am. Do you think that money grows on trees? It comes from people realizing that it's important to contribute to sustain the pieces they rely on. The majority are always free-loaders: I just think it's important to emphasize that if everyone were, the cycle of innovation would slow significantly.
We do our best to make CE and EE excellent, where the features that land in EE are mostly interesting for larger teams. For every feature that we don't bring to CE, this is always a hard decision.
I'd love to see an a la carte licensing option, where an organization could start with stock CE and license just the features they need. I realize that'd be a bear to implement, though.
I understand, and money has to be made too. It's a nasty trade off. Though as i wrote to the other reply, its the service that is worth the money not necessarily the feature(s).
IMHO, there is always a certain percentage of users that want to pay. The more users in total, the larger the amount of paying customers.
And the repo mirroring would be a great feature to let me move a lot of github project users to gitlab without losing any potential updates from an upstream source.
It would also allow for nice backup purposes, though you could do that now of course already with the hosted enterprise solution. But if the feature was in CE, many would be used, familiarised, to the feature, and perhaps see the added value of a backup node ($$) at gitlab.
Not sure why the downvote, the article keeps bagging about saving cost, when Linode would have been a much better fit and cheaper.
This isn't another ads or trolls. It is similar to AWS topic and recommending GCP, or Microsft Azure, all three are classed as similar with different tradeoff. So is Linode and DO. I do not think there are any other VPS provider then are in their class mindset wise.
Interesting. For projects that don't need a "community" we've been using Amazon CodeCommit.
We don't like to use Github anymore because of the politics there. Example: We had a project involving software filters that included this sentence in the description:
> Phase is related to time, but a pure time delay does not involve any phase shift. A pure time delay or "group delay" is constant with frequency. Phase shift varies with frequency and can advance or retard as the frequency changes.
We got a note from a woman who works at github who was apparently scanning open source projects for "offensive" words. Our project was flagged for the use of the word "retard".
We removed our project and never used github again.
Just to be clear, you're saying: "If large company x hires a single incompetent person, that is a good reason to never deal with said company again." I think that's the parents interpretation of OP and hence the "seems like a disproportionate response." (I agree it was absurd to flag the content).
That's oversimplification. Even if it is just her own personal incompetence, if GitHub just hired her and let her loose as some kind of independent repo ombudsman to scold users, then yeah, that's a terrible management decision that warrants reconsidering your relationship with them.
The point is the same though. Resting a project's livelihood on a company that employed obviously incompetent process/humans/scripts is a risky move, and removing that livelihood from that company makes total sense.
It doesn't sound incompetent to me, there will always be false positives on that scale. Did they remove the OP's repo, or simply send them a message? If a legitimate email gets caught in your spam filter, do you switch email providers? Github and their process/humans/scripts don't sound like the incompetent ones in this scenario. I would be more concerned that my livelihood depended on such an over reactionary company.
"Hey boss,I tried cloning the Github repo of project X, but it says it can't be found, and I noticed our org page on Github is gone."
"Oh yeah, they sent us a message about the use of the word 'retard' in when referring to phase shifting."
"Oh, so they deleted our organization?"
"No."
"Oh? Well why can't I view it, weren't the projects public? What did you say to them?"
"I didn't say anything, I moved us to a different host."
You're injecting a lot of assumptions into your narrative.
My point is simply: if Github is flagging content based on perceived personal morals (not ever being allowed to use the word "retard," even in legitimate contexts), some choose not to associate their work with them.
Even then, they still wrote the automation. It would be a prudent move to involve human review before emailing someone and accusing them of making a bigoted slur.
When there are numerous alternatives to GitHub why would I continue to use them? Clearly they were not putting the time and effort in to both train their employee and review the content (simply reading the sentence would give context), why bother dealing with them?
Also why as a code hosting service would they be getting involved with the politics of the content of projects they host?
Absurd being the key word. This isn't a simple misunderstanding we're talking about, it's a company employee using company time and resources (i.e. sanctioned by the larger company) for something that can charitably be described as misguided.
It raises questions about the internal company culture, their commitment to pragmatism (doubly important for a source code hosting site), and their priorities. Any developer could have told this person that a string match does not equal a linguistic match.
Small signals matter; they're usually all you get out of large orgs.
People who represent themselves as employees of a company represent the company. If the company permits incompetent employees to behave like this on their work profiles, that's not an unreasonable deal-breaker.
I actually assumed that this message was automated – "We found on objectionable word in your project, please don't use it."
It just seems that this problems is remarkably easily solved with a simple "We are using a technical term correctly, maybe you should consider adjusting your automated emails."
I do get the impression that people generally seem to be all to eager to take offence, and it strikes me as a bit ironic to flounce off in a huff as a result of a badly-judged automated process!
I find it worse. Github provides a great service and certainly has provided an incalculable value to os, but at a project level, it doesnt provide nearly enough value to dictate word choice, etiquette or style. Yes, the service is free, but github needs high caliber os projects more than they need it. It dosnt even matter who has an edge, automating spam at a user who says a naughty word is silly.
Idk, i dont understand why they would even care. Unless it reached a very intolerable bar, i dont think this is necessary
Go read up on Github user: CoralineAda [1][2] Then consider that GitHub hired her. I would not be surprised if the this automated script and her employment were directly related.
I'm not terribly surprised. GitHub is, after all, a company which changed its logo to celebrate a highly political U.S. Supreme Court decision and which has had issues with left-wing racism (http://www.businessinsider.com/github-the-full-inside-story-...).
I really don't want this to be a witch hunt (not seeing that here, just wary of pointing out individuals)—this is exactly the type of thing a business should take responsibility for as a whole. This was a process failure, IMHO.
I think you guys missed my point. In pointing out one individual, I was pointing to the organization as a whole. Github supports this kind over-sensitive social-activism. Example A: dragnet language-police script. Example B: hiring controversial, social-activists.
For better or worse, the appearance of coming from a real person seems to be the trend in marketing automation. I think many people, especially outside of tech, believe they are interacting with a real person most or all of the time, when in reality, they only are during exceptions to common requests. But people like interacting with real people more than they like seeing "automated message blah blah".
Related: The company is slipping my mind right now, but one startup changed their email name in automated messages from male to female and saw improved metrics as a result.
It's quite disappointing to see people defending a company that hires bigoted political activists to crawl users' projects in order to harass users for perceived political transgressions.
And what level of access do these on-staff political activists have to private user information? What measures, if any, does GitHub have in place to prevent one of their political activist employees from using privileged information to go after perceived political enemies or even just retaliate against users who protest being harassed?
It's quite disappointing to see Hacker News users use hyperbolic language and throw out nonsensical arguments.
What is "bigoted" about trying to avoid the user of the word "retard"? I'm not saying that what Github is doing is wise or sensible, but I'm struggling to see how it is bigoted.
> What measures, if any, does GitHub have in place to prevent one of their political activist employees from using privileged information to go after perceived political enemies or even just retaliate against users who protest being harassed?
I would imagine the same as any other company. There's nothing that would indicate otherwise, aside from your own biases against Github.
It seems like the action from the github employee was disproportionate. That sounds like a very risky environment to host your product on. The response seems to match the proportion of the action.
Perhaps to a comment from a random user, this would be disproportionate. But when it is a GitHub employee sending these messages, someone needs to communicate the issue to them in metrics they will understand, like projects leaving.
Assuming Github's ToS applied here, it's unlikely that the project owners would have succeeded in keeping the content as is on github by arguing for it. This is regardless of the legitimacy of the content. Being on Github isn't critical for every project, and we need more projects that have their primary location on Bitbucket, Gitlab, etc. instead, in order to break the Github monopoly by making it normal that it's fine to use a different site for a project.
It cannot be healthy to have all our eggs in one basket (Github), regardless of how featureful and nice Github is, especially so given the availability of viable options. To that end, we should not complain when a project, say, evil-mode is on bitbucket, and similarly not ask a project to open shop on github.
I mean, if we don't work towards a fully distributed project model ala fossil-scm (via things like git-appraise), we should at least use alternatives when we can, and not strengthen Github's monopoly.
Github does have the lead in terms of exposure and discoverability. To take advantage of that, I've left placeholders in all my projects that are elsewhere now:
https://github.com/caseysoftware/marvel-php
If you find it on Github, you can find out how to get started but everything else is on Gitlab.
we're not talking about anonymous web forums, we're talking about a git repository. It isn't "silly" to be bothered by random github employees scanning and flagging keywords
How about it's offensive that a company that bills itself as an open source hosting company even employees (incompetent) morality police? Really, scanning projects for naughty words?
Looks like a very big sign that more warnings will come later, and you'll have to spend time fighting such things now, and start worrying about your data be cut from the site without previous notice.
Going away is the correct response, fighting the decision is never useful. One might wait a bit to see if it's a fluke, but that will certainly depend on the GP's evaluation of the company.
I stopped using Github when they hired blatant racists as part of their 'social outreach' team. The infestation of politically-correct politics drives talent that can't be bothered with such cruft away.
I was there to code. Not worry about if I hurt some oversensitive person's feelings for referring to master/slave copies.
We're all on Github to write code, but I'd argue you are dangerously close to throwing the baby out with the bathwater there. It seems perfectly reasonable for someone to say "hey, this term you use might be offensive/makes me uncomfortable, please consider changing it." It's also perfectly legitimate for you to say "I don't want to do that".
I just kind of wish that everyone would be a little less sensitive about the prospect of other people being offended by things that they are not. Political correctness, in the sense of "try not to say things that are offensive" sense, is probably not the worst idea in the world!
It's "the worst idea in the world" because it perpetuates the idea that certain words or thoughts are taboo.
This doesn't mean people stop having them.
This just means that they are labelled/judged if they have them.
Guess what happens then? People keep it to themselves. And then they vote for Trump. Why? Because, he is a ridiculous loudmouth who is very out of touch with most of reality. But, he doesn't feel the need to be censored. And to people who haven't spoken out due to fear of reprisal, this is an admiral characteristic. He gives them validation.
>It's also perfectly legitimate for you to say "I don't want to do that".
At which point you get harassed by a mob, spammed with issues that clutter up your project, and get emailed death threats.
Github is allowed, of course, to choose which projects they decide to host. Demanding the removal of the word "retards" [0] or a project would be shut down drove at least one developer away.
So no - that isn't "perfectly legitimate" for that community. "I don't want to do that" is not good enough.
I think it's reasonable if only so you can avoid the overhead of needing to deal woth censors. There's also a lot of overlap between open source and free speech, so I can understand a natural distaste for censorship in general.
To olay devil's advocate, what's wrong with offending people who read your source code? You can't harass people through source code in a meaningful way because you can't force them to look at the code through natural interaction with GitHub itself, if they see a project that is insulting, they can just ignore it.
It's not like a social media site where you can ensure your victims' feeds will be polluted with your insults.
Maybe if they had some allegiance to or belief in Github fixing the issue, talking to employee, retraining them, it might be worth. But when there is another project that is just as easy to use, it often just easier to drop it and switch.
Also that interaction with Github, can be interpreted as a pointer to larger systemic issue (for better or for worse) which the customer doesn't believe will be solved with a simple email.
Given no other information I would agree. But given other information both about Github and about the kind of processes that seek you out to tell you that you are being offensive, I understand. Maybe this was a one time thing, maybe it will be another donglegate. If it is easy enough to move, why wait and find out?
A customer can choose to take their business elsewhere for whatever reason, at any time. I mean you can speculate as to whether it was disproportionate or not, but the only determinant here whose opinion matters is the paying customer.
Typically US, blocking the use of such words. Everybody says 'fuck' in the US, constantly, but whey you use it on TV or post it online, all hell breaks loose. It's just a word folks, get over it. What is the worst that could happen when you see 'fuck' or 'retard' somewhere?
I'm also curious on how many downvotes I will get for this, because the polite way is to use f*ck or something, right?
It's a political act to publicly declare something along the lines of, "I quit because of their politics."
Fortunately, people like me see such declarations — "Hmm, I'd better now reactivate my paid GitHub subscription, and stop pushing people to competitors. Their attitude is improving!"
This was also one important reason why I am switching. The price, the enjoyment of hacking are primary reasons, but the politics pathway bothers me as well.
Yes. She indicated that it doesn't matter how the word is used, some will see it as aggressive.
As she appeared to be a non-technical person mysteriously employed by GitHub as some consolation to some organization (IIRC it was called the "Ada Initiative") I realized that github is no longer a technology company. It's a Social Justice company. Good luck to them--I don't even disagree with the basic premise--but I like my git repo companies to be worried about git.
Some of the commenters here assumed that the message was automated, you're making it abundantly clear thats was not the case. In fact she defended her position. Did you try to escalate it? This is absurd.
[I'm not OP] Does one have to always make sure not to mention gender in English? I'm from Poland and in Polish you mention it all the time unless you specifically go out of your way not to do so. Before I've seen people criticized for translating "programistka" as "female programmer" and there was that proposal for some NLP library the other day, to drop any functionality detecting gender... And doing that to Polish (or any Slavic) NLP library would make the software useless: emperor/empress,prince/princess,sorcerer/sorceress - it may sound like fantasy to many but this is the reality for language with grammatical gender. I'm not saying there are no biases against women in Eastern Europe, but no one here would find mentioning gender offensive or inappropriate, in fact the opposite is true... I also don't remember such rule being mentioned in my English course.
It's not usual to avoid any mention of gender in English; some people avoid it for political reasons. But when you're translating a gender-marked word into an English equivalent which is not marked for gender, it's not idiomatic to add another word to indicate gender unless it's relevant to the topic at hand.
English lost most of its grammatical gender centuries ago. Since the 1960s and 1970s the parts that remain have become politically fraught in some circles, but usage varies by community. Unless you're deliberately wading into that fight, I'd stick to the way you were taught.
I see, recently I'm seeing people being called out on thoughtlessly mentioning the gender. The 'female programmer' was a lazy translation, agree, but I would've also used 'woman' to describe person who wrote the that e-mail if I know that for a fact that woman was the author and question by kmonsen really got me thinking if that would have wronged someone...
On a side not, I do miss that added context in English, especially in novels, when it's hard to guess just based on the names of the characters. It makes it easier for me to imagine them and evaluate interactions between them.
Perhaps she signed-off her email/post/comment with a female name? You know, it is perfectly reasonable to assume gender when the name is obvious. E.g. the odds of a person called "Samantha" being male are miniscule compared to it being a female. Because in both cases, "it" is a person we are talking about.
We can't just erase gender. People think in gender, and they consequently speak it. I don't think twice about mentioning "some guy" commented on my post, for example. Just the other day I decided to be even and refer to a hypothetical person by using "s/he", and even got called out on it.
I'm confused by your question. A lot of organizations have similar concerns. Do you believe that all discussion of diversity is equally nonsensical, or is there something about Github's stance that strikes you as especially so?
I'm in an asian country where racist is (mostly) not a thing, so why people cares about those rates is a mystery for me. In my thought, if there are 2 candidates for a leader role, and they decided "oh, we need more women in leader rank, we should chose her", it is just wrong. Race/gender shouldn't be even considered as a factor in those situations.
so why people cares about those rates is a mystery for me.
If someone rolls a die 10.000 times, and 75% of the time it lands on a six, then instead of "not caring", many people will care. Particularly those that are not betting on the six. Though the people betting on the six have a vested stake in "not caring".
In other words, it's a matter of bias.
If talent is not correlated to race/sex, then we can expect that the number of people of various races/sexes that are represented in the industry should roughly match the general makeup of the population (ie it's a mostly random distribution). Instead we see that this is not case. So either, talent is correlated to race/sex or there is a bias somewhere in the process.
> If talent is not correlated to race/sex, then we can expect that the number of people of various races/sexes that are represented in the industry should roughly match the general makeup of the population (ie it's a mostly random distribution).
Employer hiring should match the candidate population, not the general population. This is a subtle but very important difference when we also see, for instance, gender bias in graduation rates of STEM fields. (I'm not claiming that this accounts for all bias.) Really, when you say "there is a bias somewhere in the process", it must be remembered that the "process" being spoken of is the entire process that leads to a person being a valid candidate, from schooling to prior experience. (It's hard to get hired as a senior if you can't get hired as a junior first.)
First of all, there is the moral case: Certain groups have been kept away from positions of power & wealth to such an extend that taking remedial action is warranted.
Secondly: there are obviously some differences in the behavior, knowledge, and culture of different groups and it is beneficial for a company to include those and profit from it.
But... you can't have gone through more than 14 years of life without having heard all thread a few times, can you?
So you're saying there would be more mentally challenged people committing changes to open source projects, if we didn't use the word "retard" in a scientific sense referring to digital filter algorithms?
I think that's a bit of a simplistic way of looking at it. There's an easy explanation of why this approach exists though, if you agree with the following statements:
- Race, gender, sexual orientation, disability etc. do not generally affect an individual's skill as an employee
- People from certain groups are under-represented in the industry
- Under-representation generally reflects an underlying problem somewhere, because one would expect various groups to be represented broadly in line with wider society
- One of the problems that can cause under-representation is an existing bias in an industry, which can discourage other members of a group
- One of the approaches to solving this is to help ensure that those groups feel comfortable in the industry
- One of the approaches to helping them feel comfortable is to ensure that communities are inviting, open-minded, and aware that things they say or do may upset or discourage other people, even though they are do not find those things offensive themselves.
It's about observing a trend which seems wrong for various reasons, and attempting to help solve it. I don't doubt for a second that many people go completely overboard on this issue, but outright rejecting any attempt at using, say, gender-neutral language in open-source projects just seems to go completely in the other direction.
"retard" is also a correct word to use here; it means "to delay".
> If you would like to know why it's offensive to some people, I could educate you.
Could you educate us as to why it's offensive in this context? I think we all know why calling a mentally handicapped person "retarded" offends some people, but no one did so.
> "retard" is also a correct word to use here; it means "to delay".
I think its wrong; my experience of its usage suggests that is, at least, odd to use it intransitively, and, in any case, the use here might be compatible with "to be delayed", but not with "to delay" (that is, "advance or be retarded" would work, but be less-than-desirable for lack of parallelism of structure; "advance or recede", to the extent that it communicates the correct meaning, is preferable.)
All this is aside from any concerns of "retard" being used offensively in other contexts, which I think is irrelevant to the problem here.
In this context, someone stigmatized as "slow" or "dumb" by society, reading a sentence with the word "retard" in it has to deal with bad memories from the past rather than understanding the concepts in this sentence. Clearly, an alternative word choice exists. That's one reason why it's offensive.
Sticks and stones may break my bones, but words will never hurt me.
Yes, words do stir up emotions, but well-adjusted adults learn as children to control and channel their emotions in healthy, constructive ways, rather than permitting themselves to be debilitated by seeing a perfectly correct word used perfectly correctly — and inoffensively.
> In this context, someone stigmatized as "slow" or "dumb" by society, reading a sentence with the word "retard" in it has to deal with bad memories from the past rather than understanding the concepts in this sentence.
Someone so emotionally fragile would be offended even by reading your sentence about the original sentence!
But do you not understand that while writing a sentence, it is not the job of the writer to tip toe around the reader's possible negative life experience? It would be near impossible to write about anything if that were the case.
Example: In your post you used the phrase "bad memories." I have bad memories of something that happened a week ago. Thus, your post is offensive (by your reasoning).
Ultimately if you're speaking appropriately (as in, not using slang), it is the job of the reader to perceive context correctly.
A good writer has the responsibility of choosing the correct word. That's what makes them good.
I apologize if my use of some words offended you. My reasoning is that words that trigger specific memories and experiences in a person are more hurtful.
The world is not a perfect place but it is constantly changing and evolving. I keep working hard to use words that are not hurtful.
"retard" (pronounced "RE-tard") is the derogatory term, but the context used in this sentence (to slow something down) is pronounced "re-TARD". The only people who would be offended by that are those who have never been introduced to the other word with the same spelling (but different sound).
Indeed, the _primary_ listed meaning for this word [0] is the verb form, not the derogatory meaning.
Recede? Recede and retard are not synonyms by any stretch of the imagination. I'm going to assume you are not a native English speaker so I am going to include some definitions for your edification:
recede - to go or move away; retreat; go to or toward a more distant point; withdraw.
retard - to make slow; delay the development or progress of (an action, process, etc.); hinder or impede.
Imagine you are standing on a beach by a bay. As the tide goes out the water is receding. If you build a wall across the mouth of the bay, so that the high tide waters cannot leave the bay, then you are retarding the waters.
Recede doesn't mean the same thing. If something advances, then it receding means it moves in the opposite direction. If the advancement is retarded it still advances but more slowly.
Words have meaning. Words have power. This much is not in debate, as far as I'm concerned (so far). Where I have to take pause is taking one usage (however derogatory) of a word and applying to every meaning and usage regardless of what the context actually is as some manifestation of virtue signalling. At this point we may as well throw out language, diction and rhetoric entirely as any word and phrase can be twisted to be offensive even when a word is used entirely and wholly in accurate and proper context.
People with receding hairline are not marginalized by society
You're obviously not aware with how common male baldness jokes are in sitcoms and entertainment, are you? I encourage you watch a few episodes of Seinfeld to see how much influence hair and baldness has on men and their self esteem in the dating world.
They might not be marginalized, but then again I guess it depends on how one is using the word 'marginalized' to begin with, which brings us back to square one: turnabout is a bitch.
FINE. Turnabout is fair play. I think you understood precisely the point I was attempting to make specifically by phrasing it the way I did. If your analysis of communication is to unpack and divine words back to one specific meaning but not others, how do you communicate[1]? How do you know which meaning to take issue with (that's a genuine question if you care to bother) and which ones are okay? Is it just words that at some point in history been taken and used abusively? Or are they words with novelty that only now are problematic because some group has taken it upon themselves to designate them as such? How do they do so? What do they use to decide this and how can the rest of us buy tickets to ride this clue(less)train?
You are also trivialising the real suffering and daily struggles of mentally handicapped people by comparing it to the "struggle" of bald people
By insisting that we pay a bit more respect to the precedent that language is fluid, mutable and variable and questioning the behavior of linking fringe pejorative with social vernacular (or spoken like a layperson: "What, because I said words have more than one meaning and using a word by its dictionary definition in the fully correct and appropriate context does not mean I am de facto calling someone with mental disability "retarded"?)
No. Not at all. But something familiar about the accusation you've just lobbed at me, plus that utterly worthless comment about "living in the past", indicates to me I'm not going to get very far with this. So I'm gonna just go ahead and bow out right now.
You've never heard the term receding hairline? I would think that hairline would be the first thing Americans would think of when hearing the word recede. I must ask, where did you learn English?
But you're still digging in heels and refusing to entertain the notion of 'context clues' with respect to how words are used beyond carte blanche association of words and their meanings to the marginalization of social groups? I don't understand this.
> If you would like to know why it's offensive to some people, I could educate you.
In this context? I'll agree that recede might be a better choice in this case, but as an undergrad in physics I hear the word retard being used in similar contexts all the time in the sense of slowing down. It crops up especially often in classical mechanics problems.
Why should anyone censor themselves? Hiding from things that offend you is not a good way to live your life. Why should I care if some people don't like the word "retard" or "damn" or any other curse word? If you are saying it at someone in a mean way than yeah, I could see that not being OK, but censoring yourself in everyday conversation on the off chance that somebody might get offended it a terrible thing to do.
'Retard' is the correct terminology in signal processing and has been since the 19th century. You are getting downvoted because you sound as ignorant as the politician who objected to funding research in Lie Theory.
Earlier this week I had a family member get spooked by a web site with a fake blue screen tech support scam, the one where they tell you your computer has dire issues and you must pay them $300 to fix it. The page was taken down as of yesterday, but what is Gitlab doing to address this type of abuse in general?
So far every early stage startup I've seen was using GitLab unless they only have open source / public projects and can use GitHub for free or need GitHub because of the community (it's still easier to get traction on GH as an open source project because so many developers already have a GH account).
GitLab has seen steady growth for years and has recently been gaining an increasing level of attention (in part because of the pricing changes and dodgy politics at GitHub). It's here to stay.
I hope GitLab.com will become more performant and stable. I would love to see GitHub for open source be replaced with a company actually built around open source rather than proprietary tech and catchy marketing.
