Another release, another whole slew of project management features that I don't know who asked for, while things that I consider basic for a code repo manager is still nowhere to be seen:
GitLab seems to be trying too hard to replace project management tools like JIRA and CI tools like Jenkins that it's neglecting its core feature set that is code repo management.
Regarding batch review: We wanted to ship this way sooner. We spent an unfortunate amount of time refactoring our merge requests to use Vue. That is now done, so work on this has started and should be shipping on August 22nd, with GitLab 11.2. See also the epic on the subject: https://gitlab.com/groups/gitlab-org/-/epics/23
All the other issues you referenced should get appropriate priority. I recently made a change in what team is responsible for code review, so that we don't have to choose between code review and issue tracking features, but rather between different features related only to Git. This should help. (i.e. responsibility went from the 'Discussion' team to the 'Create' team).
GitLab has stated they want to manage the full software delivery process for ages now. There are other basic code repo managers out there (Gogs, Gitea, ...). GitLab is obviously able to invest a lot more in their product, but part of the reason for that is that they're not just focusing on being basic code repo managers.
For example, GitLab CI/CD is far more useful to me than configurable tab width would ever be. It's not a basic code repo manager feature, but there's a clear reason why they're focusing on one more than the other.
agreed. After a few years of this, I've given up hope of them focusing on the core project. They have basic usability errors in their merge request and approval flow that makes the product a pain. For example, in 3+ years of using the product, I still have no idea where to find all the merge requests where I am listed an an approver. Our slack channel is littered with folks re-asking people to review their code because there is no way to tell what you need to review.
But instead of focusing on the core features, here's probably what they will launch instead:
- a slack like chat app
- a trello like app
- a yammer like app
- redesigning the left nav once again
- adding even more UI clutter in the merge request box because they still haven't jammed enough crap in there
Ah, that's something else indeed. I guess it does show up in the TODO list which is the button to the right of the one I linked earlier, but there's a lot of other cruft in there, including already merged MRs.
The ToDos is a sort of inbox of actionables. We don't use approvers because we use assignees for MRs but here you'll get anything that requires (or may require) some action on your part, like mentions, assignments, CI job failures you're responsible of... ToDos get automatically "done" when you act, such as replying to a mention. Alternatively you can manually mark some issues as "done" or "to do". I like this workflow personally use them to great effect by practicing a form of Inbox Zero, and combined with the personal issues and MR lists they give me a good picture of what I have to do.
In other words, there's a number of issues assigned to me listed there, even though they're closed. There's also a few mentions that I don't otherwise interact with (I've seen them in my email and that's that), so I'd have to manually mark those as Done in the GitLab interface after reading them in my email.
We completely agree with you here. We want TODO to be meaningful and useful to everyone. The UX team is working through an exploration issue to address this, we would love to hear your thoughts on the issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/43474
All the extra features is the main selling point of GitLab. It's the reason you use it over GitHub because GitLab is more than just repo hosting and issue tracking.
The price is roughly $21 per user per month, which isn't really all that enterprisey, given you have at least 10 users, that is.
I don't know exactly how GitHub Enterprise and the GitLab Community Edition compare in that regard but aspects such as usability, maintainability and updatability are much more important than saving $21 per user per month.
So, yes if your company has a lot fewer than 10 Git users GitLab probably is the best option. In every other case, it depends and the pricing advantage becomes less pronounced.
Sure, Github definitely has worth. I use both myself.
But for a petty price, Gitlab comes with a Kanban board, a release management system, a (free) CI tool, and all of the newer features I don't have experience with ( the whole Kubernetes integration lately? ). (So no need for paid travis, Asana, Jira, ....).
Adding to that that most cloud providers offer ready to use images with Gitlab installed, I understand what it becomes such a 'default choice' for new installs lately.
Compare apples to apples, at least. The paid GutLab plans are as expensive or more than GitHub. And they keep raising their prices too cuz they aren’t making enough money to survive. The big difference for us (Apple) is performance and reliability. GitLab isn’t reliable and GitHub Enterprise is rock solid with whatever we throw at it. That’s better than a bunch of features (to my team, at least).
GitLab the company was cash flow profitable in the first quarter, with 90% margins and doubling incremental revenue (IACV) YoY. We're very much default alive.
Our biggest customer installation had a serious problem in 2015 and we addressed it. We have customers switching from GHE because of the reliability of GitLab self hosted. There are problems on GitLab.com, we made solving that harder because we insist on running the same code our customers are running, so we'll never have a repeat of 2015.
We would love to get in touch to discuss any performance problems you're still having.
> The big difference for us (---) is performance and reliability.
If that's the name of your employer, bear in mind that you can get into massive hot water for using it to endorse third-party products without authorization.
Cool to hear that Apple uses Github. I don't think we disagree.
Gitlab has had reliability issues the last months/years. Probably in part due to their rapid growth. And I still prefer the stability of the Github infrastructure compared to gitlab.com.
I was trying to say that, in my experience, Gitlab has become the defacto VCS tool for new/small companies that want something self-hosted.
What's interesting is, I do see the trend slightly change the last year, as Gitlab becomes heavier and people switching to gogs.
In the end there is probably enough space for all depending on your needs.
Ultimately, I think, Git is a PM tool. Its benefits are __not__ exclusive to programming / code. The future for Git is much broader. GitLab is likely positioning, leading, and leaning into that future.
In all the scenarios I've been involved in implementing a new version control solution, there are already existing project management and issue tracking solutions in place, and appearing to want to replace them is a hurdle to be overcome rather than selling point. We use Gitlab, and the CI and Issue tracking features all sit idle, but better integration with Jira would be valuable, cause ain't no way we're switching issue trackers.
GitLab has moved past being a "a code repo manager" and is creating a tool to manage the entire SDLC. My reaction to this is the opposite of yours. Adopting it has already allowed us to get rid of Jenkins (shudder), and will soon allow us to replace Jira as well. Your wishlist is reasonable enough but I like the direction they are going.
Exactly. We support Windows runners for several tools and they work fine. Our developers delight in adopting obscure build tools and we have been able to support them all. On a humorous note, when I told my management that we had updated our process to support "yarn" and "gulp" they wondered if I was just making stuff up.
Can't you do Windows runners even on cloud? I thought there was a callout on their pricing that said that your custom runners don't count toward usage metrics.
Agreed that GitLab could really do with some development of boring, unsexy, wholly necessary features now that they're seeing some well-earned adoption. Please, please, please add batch review.
Add to that list that big diffs with many files (which are a bad practice, but do happen) causes the entire browser tab to freeze up.
Hi. Co-founder of CloudBees here (and sometimes contributor to the Jenkins project). I have described the UI as far worse words than that myself, but things are changing:
- Jenkins X - which is really about how you build apps on Kubernetes: https://jenkins-x.io
- We also have https://CodeShip.com - for those that don't need the on-prem/self hosting flexibility/extensibility and want things to work as a service.
Its great to see so much activity in CI/CD these days, really cool to see. Hopefully if you run into Jenkins again one day in the future it wont be the one you have a bad memory of.
It's definitely not exclusive to gitlab/hub/whatever. You've been able to do this on mailing lists when reviewing a patch since, well, ever since email was a thing.
>GitLab has memory leaks. These memory leaks manifest themselves in long-running processes, such as Unicorn workers. (The Unicorn master process is not known to leak memory, probably because it does not handle user requests.)
>To make these memory leaks manageable, GitLab comes with the unicorn-worker-killer gem. This gem monkey-patches the Unicorn workers to do a memory self-check after every 16 requests. If the memory of the Unicorn worker exceeds a pre-set limit then the worker process exits. *
I know this is a Rails issue, but I cannot believe this is still a problem. I remember when the RoR folks blamed the Rails memory leaks on Zed, and Mongrel, more than a decade ago. They were obviously incorrect. Did the community simply give up on fixing the problem?
I don't know anything about Rails but most memory leaks in managed languages are stuff like lists growing infinitely large, parts of them pointing to data that is no longer relevant. Think badly implemented caches, stuff like that.
If you have enough not-perfectly-cleanly-separated layers of data management interacting, then this gets hard to debug pretty fast.
Why are they still using unicorn over Puma? That’s one question. Using unicorn killer is the sign of some bad engineering. It’s the equivalent of restarting your server every hour.
We are planning to start using multi threading and Puma so we can reduce the memory requirements of GitLab. The last time we shipped that we had to revert due to hard to diagnose errors. We're taking a more incremental approach now.
Were you under the impression that Rails has a functioning dev community?
I am very familiar with the rubyverse, and boy do I got news for you.
Rails is to Ruby as the Big Dig is to Boston.
But it's hard to get Rails devs to admit it. They know it, of course. They live it. They breathe bad code, they exist as extensions of a philosophy that has failed it's way to the top.
I used to think Zed was a dramatic weenie. Then I got a bit deeper in Rails to learn how to pursue better exploits. And deeper. And deeper. And finally I just hit a point where I just wasn't willing to work on RoR-related gigs.
Convention over configuration is one of those ideas that goes great on paper. And then you start in on some buzzwords and fancy lingo, it's the bread and butter of selling to project managers. But there is a point where CoC breaks down at a technical level, and that point is literally the first moment you come across something difficult to express
Rails is weak in doing things ANY other way than the Rails way, and what developers do (and it's not their fault) is using their creativity and ingenuity to solve the problem. I believe this is why metaprogramming in Ruby has such a vocal backing, because there are millions of shims holding up millions of Rails' shitty choices that depend on method_missing fuckery or string-based define_method gadgets. In the spirit of what it means to solve hacker-ish problems, it's great fun to program like that for a while, and then a year or two down the line you look at that shit and it can really break you down. Good developers mistake themselves for bad developers because of this, to be honest.
Zed's probably had the idea to write an entire book of how insanely FUCKED Rails actually is, but to make the book plausibly thorough would mean a human being being exposed to far more stupidity than modern science can safely treat for. It'd be dangerous to have that much stupid intake just for a book.
That unicorn-worker-killer gem is a perfect caricature of the kinda problem-solving you run into with Rails. Let it die a horrible death, restart that shit with some logic to let it keep dying predictably.
That technique, multiplied by every component in the system, multiplied by every developer on the team, multiplied by MVC requiring developers to have to know too broadly the system they're working on, multiplied by however many years and Rails versions the project has somehow survived, you approach something I can only imagine is quite similar to what hell must be.
I spent 3 years working on a Rails app and it was enough to make me swear off Rails for the rest of my life. I think the Rails dev community has good intentions, and the design of Rails is actually pretty nice. The problem in my opinion is more with Ruby, and human laziness. Ruby lets programmers do absolutely anything they can think of no matter how unexpected or un-intuitive it will be to their colleagues. Combined with the rigid conventions of Rails' design, this inevitably leads to a maintenance disaster with people, like you say, getting too creative.
Refactoring a large Ruby on Rails codebase is basically impossible. There's no compiler to help you along; hell the code is evaluated lazily. So instead of refactoring, people monkey-patch their problems away. It's horrible, really really horrible.
I'm now getting flashbacks to trying to understand how files get loaded in that codebase... I need a drink
I don't completely get this sentiment. Is refactoring a big java program easy? Yes, you will get nice hints from the IDE, but who knows how many things you screwed in the process of refactoring that the compiler isn't telling you about?
Especially when it's not your code, when the person who wrote it isn't there, when you're not 100% what the code is actually doing, when it's undocumented and the intent isn't clear etc etc. Or worse when there aren't any tests which I'm sure happens a lot in java land.
Why would this be specific to Rails?
You're making it sound as if the twitter team can rewrite their app in 2 days because of 'compiler'.
Big complex projects are big and complex. In Java / C# / Scala they're even bigger because of types, interfaces, traits and other kind of verbosity. It makes it harder to wrap your mind around the application in the first place.
It seems like you’re taking this a bit further than the parent comment said - e.g. there’s no claim that any major piece of software can be refactored that quickly, however the general process can be made simpler and safer with decent static tooling.
As a concrete example on a small scale of something common such as renaming a model field name. Given that ActiveRecord reflects the database and generates the methods dynamically there’s pretty much no good way to refactor that field easily. It requires a lot of manual searching/filtering to find possible usages and then time on that to ensure it’s not a shared name on a different object type. From what I’ve seen in many code bases it ends up manifesting as `delegate` usage and often just expands the API exposed by the model.
Compare that to something compiled, or even something like python that doesn’t encourage meta too much, and you can pretty much find all symbol usages with whatever intellisense engine you prefer (ctags, JetBrains, jedi, ...)
I agree static analysis can help. Specifically for changing column names it just doesnt really happen that often in most projects I worked on...so I never really thought it to be a big deal.
Then you're lucky. I specialize in refactoring and reorganizing extremely messy and large / complex applications. And Rails is my fucking nightmare. Especially when untangling ActiveRecord callbacks, fat controllers, convention over configuration, magic method, and database changes.
I would give a kidney to have static compilation in rails when refactoring.
That goes to my point, rails doesn't have the symbols in code for the editor to use to refactor because they are added at runtime dynamically when ActiveRecord reflects the database. You can have a full model that just has `class User < ActiveRecord::Base; end` that has 15 fields on it, none of which are in the code.
> They know it, of course. They live it. They breathe bad code, they exist as extensions of a philosophy that has failed it's way to the top
I think this is a dangerous line of thinking. This crosses the line of being productively critical of a language or a framework into actually attacking people.
By promoting this line of thinking, you increase the tolerance of this kind of attack.
People arrive at their personal choice of language and framework as a function of their environment, their education, their first job, what's popular at the time, and myriad of other factors.
I am sure you have preferences for languages and frameworks, and I'm sure there are other people who don't agree with them. Do you want those people giving you reasoned arguments about why you should change your preferences or, do what you did, make allusions that you are so irredeemably stupid that you physically exhale shoddy code?
My day job is working on Rails apps (most of the time anyway -- we have a diverse infrastructure). I'm not a big fan of Rails architecture and struggle to communicate to others why I think the "Rails Way" is not necessarily a good way. But these things are hard to swallow, especially if you haven't seen anything else before.
However, I have a special dislike for "convention over configuration". What that really means is: You must write code my style. As there is no configuration, it will be difficult to discover what that means by reading the code. You must study and memorise the one true way. If you deviate from it, strange things will probably happen and it will be your fault for not doing it my way.
To be fair, Rails documentation is really very good. Also, this is a selling point for the framework. If you give no choices then everybody must do it the same way. Even if that way is stupid. You can hire a whole bunch of people who "know rails" and they can struggle along and make progress. You don't have to trust them with decisions because the important decisions were already made for them.
I've had a wide and varied career before doing this work. It's hard for me accept "because it's the Rails Way" to questions like "Why are we doing this when it is causing problems?" I don't mind people making mistakes as long as it is not a thoughtless mistake. "I thought this would work, but I was wrong", is a wonderful sentence in my book. Unfortunately that's the kind of action that many programmers are dissuaded from taking -- instead they are encouraged to do it the "Rails Way".
Lots of beginning programmers also prefer it this way. When you are first starting out (and... well... even when you've been doing it for a couple of decades) it's hard to know which way is better. You might even have a preference, but then struggle greatly when someone asks "Why is that better". Especially beginning programmers often get stuck without knowing any way to accomplish something. In those cases, the "Rails Way" is extremely comforting. 1) It's a way. 2) It will probably work (at least grossly) 3) Famous people say it's good, so it's very, very comforting to agree. People entrenched in the community reinforce each other until it seems practically impossible that there might be a better way. But they may not have looked.
Of course Rails is not the only "Way" out there that espouses these ideas. It's just a currently popular one. What's really at fault is the "convention over configuration" attitude -- Don't think; just do it my way. I hate that.
Rails is popular as startups because it's easy to pick up as a first language meaning the labor market was cheap and flooded with coding boot camp grads. Startups love cheap labor and they don't really care if things are built to last or will scale. They only care about it lasting until their next funding round or (hopefully) their exit.
Rails Devs are well compensated...where are you getting this from? Yes rails is more suitable for rapid development than spring, and easier to teach and learn. How is that bad though
I love Rails for certain projects, but it's definitely true that at a certain point things start to break down. Maintaining a large complex application with Rails is not fun at all. ActiveRecord is amazing, until it's not.
IMO, you can still learn tons of great practices with Rails, and for certain projects I still think it's a great choice... But you have to know when to drop it and move on to more robust solutions.
Like most engineering tools, it makes certain tradeoffs, and you have to know how to pick the right one for your job.
You're absolutely right, you're just completely ignoring context. Some things break down a lot sooner. Eating or drinking too much of anything can kill you, even water. But drinking acid will get you there a whole lot faster. Rails is the acid of the programming world.
After many years of working on a variety of Rails projects, I've pretty much come to the same conclusion and, if you look at it another way, it's the same conclusion no matter what you work with.
Rails is incredibly effective for solving the problems that existed at the time it was conceived. CRUD websites, rapid prototypes, things that aren't incredibly complex. Not an exhaustive list, but that's what I reach out to Rails for now.
Once you get past that certain point, not only does the framework fail to offer a convention for the problem you might face, but it also requires a mature team of developers to guide things forward from that point on, and really think about how to build something that Rails itself has no decent answer for. That solution might be to break out of Rails, or switch to raw SQL queries, or to proxy to services that can handle the task better. It's almost never a good idea to double down on the convention at that point.
Not to detract from the Rails situation because I largely agree with it, but there are also issues with Ruby's memory management, as some memory just can't be reclaimed. Rebuilding Ruby with jemalloc helped in mitigating rampant memory fragmentation for our loads and use cases, but things can only go so far regarding how things are managed. At some point the processes need recycling, so yes, most literally, regularly reaping the workers is most literally a robust way to perform an OS-level sort of GC, as in you're 100% sure it works with any reliability, and even though it may hurt some theoretical sensibilities this is a very hands-on, practical solution.
You are blaming Ruby? Plenty of major orgs running Ruby at scale aren’t resorting to restarting the server to solve memory leaks.
It is a practical hands-on solution. However it’s also bad engineering. I too have used unicorn-killer and it was always the result of trying to make bad code not crash our servers. It is a lazy hack solution that I used because it was easy and at the time didn’t know enough to fix the actual issues. I was inexperienced. No disrespect intended but with the suggestion that essentially restarting the server is a robust strategy against memory leaks, it’s kind of hard to be confident of the technical robustness of the platform, especially at scale.
I can guarantee that Github isn’t using unicorn-killer nor blaming Ruby for performance issues.
Agreed. As someone who has worked with Rails over the past 9 years, the only time unicorn-killer is generally used is to save an application from very bad engineering. That’s it. That’s the only reason to ever use it. No serious (or even not-so-serious) production app should be using unicorn-killer as a strategy. Ridiculous fail. Rather than releasing shiny new stuff, it might be wise to fix the core issues with the stability of the system first. Using New Relic or Skylight should at least help narrow down where the memory leak originates.
I know we are supposed to be “Hurray Gitlab! Open core!” but it feels like GitLab support around here is contrived and astroturffed, by GitLab insiders. Any company that actually claims unicorn killer is a robust way to handle memory leaks has some extremely incompetent technical leadership. The robust way is to not to have memory leaks! Essentially restarting your servers all the time (which is what unicorn killer practically does) is a ridiculous way to handle memory leaks.
I feel they're making it harder to review a merge request with multiple commits. It used to be able to click on a commit and get succinct view of the actual commit with title and message. Now days after clicking on a commit, you have to scroll down and skip a lot of irrelevant information to find the actual commit content - and gitlab by default hides the commmit message! This makes it very cumbersome to review a MR with many commits, and also harder to train new developers to learn the advantages of making good commits.
Being able to review per commit in a merge request was a major reason for my company to choose gitlab back in the day. A merge request consists of a series of commits, each doing a single change (basically the same way linux's patch series works: https://www.kernel.org/doc/html/v4.16/process/submitting-pat...).
I'm hoping gitlab will improve the experience in the future for us that want patch series style merge requests, but I'm worried that gerrit style development is winning where the result of each merge request is supposed to be just a single squashed commit.
Thanks for the feedback gorset. I'm curious to dig a little deeper.
With the irrelevant information, you mean the top part of the merge requests (ie description, CI status, etc)?
And as far as I can see, in the current version, we only hide the body part of the commit message.
I think we can make the experience better by autoscrolling down once you click on a commit in a merge request. I've made an issue [0].
I'm not sure about showing the full commit message. Many would argue that only the first line summary is crucial to show, which is what we do now. But I'm happy to discuss.
This might be a difference in expectations, where we are talking about two styles of merge requests. I believe they can be both supported well by gitlab (in fact, I consider gitlab to be the best review tool out there because it has support for both styles).
## Gerrit style MR
Mostly a merge request with a single commit. All relevant information is placed in MR title/description. If there are more than one commits, they are usually added to review the first commit based on review feedback or problems detected by CI. The commits are often squashed before merge to master, so the individual commit messages are secondary to the MR title/description.
## Patch series style MR
A merge requests with multiple commits, each containing a single logical change. The MR title/description only contains high level information/summary - more detailed description is found in the commits.
If serious problems are found either by CI or reviewer, the developer often amends the commits rather than push new commits on top. The reason why is that each commit should be as complete as possible, which helps reviewing, git bisect and keeping a good git log history.
This style requires more upfront work by the developer, but the advantage is that reviewing becomes easier. Instead of reviewing a large diff with many different changes, the reviewer can look at a single commit at a time. Some types of changes such as refactor, reformat can quickly be verified and reviewed because they are not making any semantics changes. A commit containing a bug fix is much quicker to review if there are no refactoring, reformating or other semantic changes in the same diff.
Good commits should also have good commit messages, which describes what, why and why like /this/. Just as important, this information should be easily available when reviewing the merge request. It should be easy to iterate through all the commits in a merge request, reviewing both the commit message and the commit diff for each commit.
With the latest changes of gitlab, I feel it's being optimized for Gerrit style merge requests, in which case your comment make sense that you're not sure about showing the full commit message. However, for me this is a major step back since we do patch series style merge requests where each commit is often reviewed individually.
Thanks gorset for the great response and the new insight you gave me into this. I now understand what you mean and see how the changes have negatively affect patch-series style MRs.
We're not fans of adding additional configuration, but I can imagine we store e.g. what the last state was that you left commit message in, as to not have to unfold it every time. I'm sure you have further thoughts on improvements that can be made.
libobs: Add scene item grouping
Allows the ability to group scene items. Groups
internally are sub-scenes, which allows the ability to
add unique filters and transforms to each group.
Without the full message, I would not know what this commit brought until the changelog is updated on release. Now I know what to expect and why is was committed. In a merge request, I would like to see the same level of reasoning. For example, if there was a new commit pushed in a MR that I already saw that changed one line, I would prefer to see reasoning behind the change.
We've been paying for GitLab for about a year now, and it's mostly been a good experience. There have been three things that seem to come up weekly for us:
1. Lack of traceability/auditability. We're in healthcare, and have a regulatory burden that requires versioning of basically everything. GitLab does this for code and wikis (thanks to git itself) but not for issues, merge requests, comments, etc. I've ended up building a service that just ingests the webhooks for these to store them away, which feels ridiculous. Since the webhooks for comments doesn't get triggered on update, I even have a TRIGGER shimmed into GitLab's postgres DB. Ech.
2. There's no concept of a bot user, so every integration we want to do is against a single account/identity, in part because...
3. The pricing of Ultimate feels ridiculous, and that's the only way to get something as fundamental as epics. $1000+ a year for every employee?
[edit] $1000/mo -> $1000/yr. (per month would have been even more way cray)
1. I'd love to see everything versioned in GitLab. We're working on the issue descriptions, but I agree we should move toward versioning everything. There's an epic here [0], that we will be filling out with more issues to address what we haven't yet. Feel free to leave feedback there as well.
2. Most integrations are against projects, groups or instances. For those that require an acting agent, I recommend just creating a normal account for that and call it bot. I think it makes sense for us to have some sort of permanent solution for bots [1]. In the meantime, I propose you talk with our sales team about that. I'm sure they're willing to be flexible.
3. We believe the pricing for Ultimate is fair, given the broad range of tools GitLab replaces, from project management, to CI, to security, licensing and container management tools. That said, we're aware that it's challenging to see the value for every single user. With this release we're taking a step that hopefully helps out, by making guest users free for Ultimate [2]. We welcome further feedback on how we can make GitLab even more accessible to everyone in the organisation.
As the author of one of these projects (sit.fyi), I'll be happy to show and explain its philosophy & benefits (some are quite interesting and yet to be possible in conventional options). I think that discussion can be of value to all. Feel free to reach me at me-at-yrashk.com if interested!
You might want to check RhodeCode at some point. Because our main customers are in Healthcare/Insurance/Automotive, and all those industries require strong auditability. We built very advanced audi logs capabilities, every permissions change, every comment, is traced with IP user and old data is saved.
In addition to [0], to version-track issue/mr descriptions that was already referenced earlier (within an epic), we also have [1] open, to do the same for comments. Please feel free to comment more there!
If you export and parse the logs (which you should). But out of the box all kinds of write level or auth interactions aren’t exposed in the audit log search UI.
I haven't checked out v11 yet, but since it's not yet mentioned I assume the admin UX hasn't been addressed. Of all the tools I have admin on, Gitlab's admin UI (spread out across multiple sections) is perhaps the most sprawling and confusing. For example, there are two "repository" sections in each repo (one top level, one under settings) - in one you can perform repository admin such as branch management, and in another you can configure things like deploy keys. The groups/users/repo setup is another example of a clunky workflow - functional, but too many steps, and stitched together CRUD UIs. I get the feeling no product manager has sat down to address admin cohesively for a number of years, but rather that it has just grown organically.
My other big wish for the product is better CI. Gitlab certainly makes Travis unnecessary, but it doesn't scratch the surface of the functionality that Jenkins provides via the plugin ecosystem. Yes Jenkins is janky (although can be made to look nice enough via themes) - but Gitlab doesn't even address parsing xunit results and displaying trends in a project centric reporting location (https://gitlab.com/gitlab-org/gitlab-ce/issues/17081), instead steering you towards build centric "pages". Get the reporting built out (and also allow it to natively consume/parse/understand output from major testing & static analysis frameworks), and it would be a more compelling alternative. Nobody wants to look at hundreds or thousands of lines of build/test output - the CI tool should summarize the reasons for success or failure.
Finally, we're having to run our self-hosted Gitlab on an absurdly large EC2 instance (8 cores, 32GBs). Occasionally we'll have a dozen people converge on a single important PR for review, and before upgrading to our current server this type of event would often bring our instance to its knees. Language choice may be a significant contributor to this -- rewriting major parts of the backend in Go or some JVM language would probably be a good product goal.
You're right. The UX in GitLab's admin settings has lots of room for improvement. The good news here is that we now have a product manager devoted to this area, and have a number of improvements scheduled here that should help. A few I'm excited for that we're hoping to schedule for 11.2:
GitLab now runs a copy of the rails stack under Gitaly because the git Go libraries don't support everything GitLab needs. So ironically moving to Go caused GitLab to use more memory. This will be fixed in Gitaly 1.1. There is no due date for that.
It might be interesting to someone that GitLab is not seem to be compliant with current European data regulations (GDPR), it is worth reading their terms and privacy statements [1][2]. E.g. even self hosted GitLab phones home in opt-out fashion.
GitLab collects information about usage from each self-hosted GitLab instance (Community Edition and Enterprise Edition) through a usage ping. The usage ping sends a payload containing data such as total number of projects and pipelines, as well as license information and hostname to GitLab.
...
The information from the usage ping is not anonymous, it is linked to the hostname of the instance [3]
...
The documentation is a merge request [4]
This MR loads the EE usage ping asynchronously on the admin application settings page and now includes the counts of the following items:
Comments
Groups
Users
Projects
Issues
Labels
CI builds
Snippets
Milestones
Todos
Pushes
Merge requests
Environments
Triggers
Deploy keys
Pages
Project Services
Issue Boards
CI Runners
Deployments
Geo Nodes
LDAP Groups
LDAP Keys
LDAP Users
LFS objects
Protected branches
Releases
Remote mirrors
Web hooks
Remember that the GDPR only applies to personal data. That is defined rather broadly, but it still might not apply to all the information you've mentioned.
In the EU IP alone could be considered PII, it would seem logical that hostnames are too, but I never saw it spelled out. The counters are sent in combination with these identifiers. The summary above is compiled from GitLabs own sources. Most probably don't care but some might.
that statement is wrong.
first of all IP Addresses are only PII if you store them to identify users, means that if you are user table has an ip_address field, it is, however...
if you store all ip's accessing your service in a database to find malicious logins it isn't.
so basically the statement is, it depends.
the connection of user to ip makes it PII.
I think we agree context is important. However GitLab is collecting IPs in combination with hostnames, not to mention the rest of the traffic that could easily be used to fingerprint users.
GitLab obtains affirmative consent to its use of personal data under privacy policy, plus users also have the ability to opt out if they wish revoke their acceptance.
GitLab offers a blanket checkbox on signup with a bunch of legalese, there is no fine grained opt-in to the data collected. Worse, as you said, it is all opt-out.
Is there any timeline for monorepo support? The ticket has been sitting in the backlog and every once and a while I get an email when someone bumps it. I with this feature got some love so service oriented architectues were more manageable
Hey sytse. This is the issue number [0]. There's a few people at the company I'm working at who have been pushing really hard to move away from GitLab to GitHub. One of their main issues, from what I can tell, stem from this issue and getting some integrated support for monorepos. I'm very glad you're working on the features monorepos require.
Aside from monorepos there is one other small issue I have with GitLab. GitLab is perfectly well situated to completely take over the software development planning, warehousing, deployment, and testing. Documentation is really the last front. If GitLab wikis were as powerful as Confluence I would be very happy because I'd never need to use that terrible bloated site ever again. I've been pushing for us to switch to GitLab wikis for a while but 2 coworkers keep saying that "it is not good for long-lived out-of-project documentation, it's not as searchable, you can't drag and drop for graphs, it's not as integrate, and it doesn't have as many features as Confluence".
I hope one day GitLab can be my one-stop-shop for everything.
Thank you very much for making such an amazing product.
Thanks for linking the issue. I'll discuss it with our product leaders.
Regarding the documentation we see many people switching to static websites generated with GitLab pages. This allows you to separate the change from the approval. Is this an option for you?
Personally I think that works and gives you all of the "edit-locally" benefits (Accessibility, hotkeys, versions, distributed/backed up etc). What that doesn't give you is a few other important features.
My coworkers are concerned with the following:
- Highlight and right click docs -> new ticket
- Drag and drop flow chart creation
- Non-developers can document and plan
- Full text search
- "Name spaced"/grouped documentation
- Third party integration
I agree that most of those are not in the wiki nor in GitLab pages.
For non developers you can make it easier to edit by linking the bottom of each page to the reposity. See our website or docs pages for an example of that.
It already is? If I visit a single commit's page, in the Options drop-down on the top right-hand side I can click Revert, and a modal pops up asking me in which branch I want to revert that commit.
Hmm, what magic is that? It appears to create a new branch with the revert, and create a merge request from that branch to the branch I select - which is what I expected. This is of course with "Start a new merge request with these changes" checked. When it's unchecked, I'd expect it to make the revert commit directly on that branch; is that not what happens?
linked merge requests would be my killer feature. VERY often we need to change multiple repositories at the same time. Like for example backend+frontend changes that's in different repositories. Having a linkage between them, that would make them be merged together would be awesome. And also prevent merge if one is "wip" or unresolved discussions etc...
We're working on this! We've wanted to explore this for some time; we're tentatively calling this a "super" MR and putting some design time into 11.2 to understand how this might work. Lots to think through here. Love to get your thoughts in the discussion so far: https://gitlab.com/gitlab-org/gitlab-ee/issues/3427
Cool stuff, way more advanced than I thought of. I don't have an account but might create one, on phone right now. But I drop my 2 cents here. I rather see a free version with a simple relationship between MRs.
Basically;
If linked_mr:
print "warning, merging this will also merge:" + linked_mr
...
Function merge()
...
if linked_mr:
merge(linked_mr)
I mean, isn't it the whole idea(centralizing) so we can work together? And what do mean with 'our' who are you? Also are you aware you can have your own instance?
I'm not offended at all by using the word "master" where it makes sense. However, as a role for users, is sounds sort of odd and a bit authoritarian. I think "maintainer" is a nicer choice regardless of any political-correctness driven reasoning.
If we're talking about user roles for users with the implicit implication that it indicates a position relative to others, I'd say "owner" is worse.
In this context, though, the subject is the repository, an inanimate piece of property, not any other user. In that context, I'd argue that both "owner" and "master" are descriptive and very difficult to interpret offensively unless you're going out of your way to interpret them as such.
There are subtle differences in connotation between "master" and "maintainer", too - think "king" and "steward", apologies to Tolkien - it's not like they're synonyms and a swap is just being done in-kind. I think there's actually a case to be made that "maintainer" is a better label for the role, given the existing context of a project maintainer being one who has administrative control over it (and the existing "owner" root role), but to change the label with the reasoning that "master is exclusive, so we picked up a thesaurus" isn't going to pass the sniff test for a lot of people. A slightly more tactful approach of "we decided this better describes the role as it already applies to modern team organization" would have worked just fine.
Being inclusive doesn't mean thinking up ways yourself or others might possibly ought to be offended and avoiding them.
This sort of overoptimistic "inclusiveness" is the kind of thing that makes the people who doubt much more certain of their skepticism and should be considered harmful.
I'd also argue that it's exclusive of people who dislike arbitrary impediments to their dev work. Words like master and slave have semantic meaning going back decades in computing. Avoiding their use introduces ambiguity and makes everyone's job harder. We should be striving to reduce the number of synonyms for things, not introducing more for questionable reasons.
Have you considered the possibility that people other than you do find the terms offensive, and have asked for them to be changed?
> This [...] is the kind of thing that makes the people who doubt much more certain of their skepticism and should be considered harmful.
Those of us who live in the US are painfully familiar with this line of thinking... "you better change your ways if you want to convince me about this whole human decency thing! I'm still on the fence about being an asshole, and it's all your fault".
Guess what, nobody cares about your skepticism, because you're not in a position to decide on this issue, thankfully. Nobody is trying to change your mind, either. All that we ask, as a society, is that you keep your intolerance within the scope of the law, and refrain from killing or beating people as a result of your bottled up anger and sense of entitlement.
>Have you considered the possibility that people other than you do find the terms offensive, and have asked for them to be changed?
I have considered it. I would indeed be eager to speak with someone who actually was offended by the term. That is not someone who is offended because they believe it might offend a third party, someone who themselves feel hurt by the prevalence of calling a computer a "slave" or a person a "master" in this context in a way they believe is _significant_ and _important_.
I would love to talk to such a person and understand their perspective, but the point I am trying to make is I seriously doubt such a person exists.
I would also like to know if such a person would also be offended by the word "robot" which is a loanword meaning literally 'slave' in Czech.
There is a rising problem in society of people who ally themselves with straw-men and make moral issues in support of dubious claims of oppression. To be fair, it isn't a new problem. Virtue signaling or boasting of one's own moral superiority by shaming others is as old as society. In the last century in America most of this was about being a good Christian. This century we're in a transition towards greater irrelevance of religion and conservative morals, with the new most popular moral boasting point being about who can be the best liberal.
My point is not that issues of tolerance do not exist in our society, it is that increasingly, many people talking the most about tolerance seem to be doing so to further their own feelings of moral superiority and to display that to their communities. There is a disconnect between their actions and actual empathy for real people they encounter.
That is, to come back to the original point, nowhere can I find evidence of this change being attributed to empathy towards a real person who experienced grief. Just a lot of talk about people expecting the change will make people they suppose to exist feel better. That sort of empathy for the strawman is harmful because 1) it distracts from actual issues and 2) it diminishes the position of people talking about actual issues.
> I think being inclusive means removing obstacles you might not see yourself.
Agreed, yet I'm kind of concerned about those context-free word readings and absolutisms, which can deviate into a form of thought policing, censorship, and sometimes, bigotry. While it is important to take care of the weight words carry and be humane and respectful, words do not make sense without a context thus I have no problem with a process being "slave", because it has a very precise meaning in CS/IT nowadays entirely remote to the origin and history of the word, and not entirely encapsulated by "secondary" which is somehow more fuzzy. By that metric we should probably soon stop killing processes (oh, my! parents killing their own children!) and having daemons and so on.
Trivia: for maximum shock value about how context shapes word meaning and your perception of it, in French the n-word means both "a person of African ascendance" and "ghostwriter", and for the latter synonyms fail to capture the essence of what a ghostwriter is. So, yes, "nègre" is definitely used without offense when the context of literature is made absolutely clear, although it is tentatively replaced by "prête-plume" or "écrivain fantôme".
Why? It makes perfect sense. It's not the primary. That's it. The master slave means the same thing. They are just labels in a replication state machine (or system), you need to know the precise meaning behind them anyway.
Maybe Leader Follower is the best (zookeeper and kafka uses it also usually any distributed system, that has dynamic election).
If words on a screen are obstacles, maybe software isn't for you.
There are people who have survived ACTUAL obstacles like slurs being shouted at them, growing up in bad neighborhoods, surviving inner-city schools, they've got REAL SHIT to work through, and they managed to become competent, effective developers despite all that.
At some point, most proponents of """inclusive""" pattersn are nitpickers that fragile non-hackers are glorifying as arbiters of social consciousness and morality. It's dysfunctional and dangerous to empower people in such a broken frame of mind.
"Los Angeles officials have asked that manufacturers, suppliers and contractors stop using the terms 'master' and 'slave' on computer equipment, saying such terms are unacceptable and offensive."
We got extensive feedback regarding the `Master` title. Renaming it to `Maintainer` is a relatively cheap thing to do, strengthened by the fact that it's a better reflection of the permission level: this is what Maintainers of repos will typically have.
Not really, maintainer is a more vague term implying any level of access and authority. Plus its more letters to type out forever over and over because someone theoretically was crying over this.
Which no doubt comes from the term "master copy", which has a long established, and quite precise meaning. Choosing a different meaning arbitrarily(or actually, quite deliberately) is disingenuous at best.
Calling someone master can deeply offend. Are we really at the point where we cannot distinguish between a human being and an incorporeal blob of computer code? Life is going to be really, unnecessarily challenging if you go through it bending over backwards to invent new ways to become upset.
It's nice that this doesn't bother you, but if you're not going to learn about and respect how words make others feel, at least have the decency to keep your dismissal to yourself.
I challenge you to actually find someone who is offended by how these words were being used, not offended on behalf of someone else, but themselves felt hurt by the usage.
Can you link to a time where the majority of a thread has hated on Gitlab? Maybe the one where they don’t pay too much and have a scale based on location, but I might be forgetting the ratio of hating and that wasn’t a topic relevant to Gitlab as a software project.
Otherwise it’s usually at least some or majority love for Gitlab on HN.
If you are using the Omnibus package on Ubuntu, don't upgrade! It just broke my instance. and can't find out what's wrong. Great features... It was a big mistake to trust GitLab, I already predicted they will have problems.
No, I'm not joking. I've had the omnibus package break my Gitlab as well and the bugs survived even full reconfigures and restarts. Rebooting the server fixed it even though it makes no sense.
Another release, another whole slew of project management features that I don't know who asked for, while things that I consider basic for a code repo manager is still nowhere to be seen:
- batch review (seriously, will this ever be done?) (https://gitlab.com/gitlab-org/gitlab-ee/issues/1984)
- configurable tab width (https://gitlab.com/gitlab-org/gitlab-ce/issues/2479)
- consecutive git blame for current revision (https://gitlab.com/gitlab-org/gitlab-ce/issues/37135)
- rebase and merge in one single step (https://gitlab.com/gitlab-org/gitlab-ee/issues/895)
- unable to view diff for any file that is slightly large (https://gitlab.com/gitlab-org/gitlab-ce/issues/30061)
GitLab seems to be trying too hard to replace project management tools like JIRA and CI tools like Jenkins that it's neglecting its core feature set that is code repo management.
Thanks for the feedback. To address some of it:
Regarding batch review: We wanted to ship this way sooner. We spent an unfortunate amount of time refactoring our merge requests to use Vue. That is now done, so work on this has started and should be shipping on August 22nd, with GitLab 11.2. See also the epic on the subject: https://gitlab.com/groups/gitlab-org/-/epics/23
All the other issues you referenced should get appropriate priority. I recently made a change in what team is responsible for code review, so that we don't have to choose between code review and issue tracking features, but rather between different features related only to Git. This should help. (i.e. responsibility went from the 'Discussion' team to the 'Create' team).
Regarding viewing large diffs: we're working hard on a better solution. Follow the epic for the full picture: https://gitlab.com/groups/gitlab-org/-/epics/15
I’m already following the issues but since you’re here please, please can we have merge + tag in one step and also rebase + merge.
https://gitlab.com/gitlab-org/gitlab-ce/issues/22363
Cool feature. Makes total sense. Pinged the relevant people.
GitLab has stated they want to manage the full software delivery process for ages now. There are other basic code repo managers out there (Gogs, Gitea, ...). GitLab is obviously able to invest a lot more in their product, but part of the reason for that is that they're not just focusing on being basic code repo managers.
For example, GitLab CI/CD is far more useful to me than configurable tab width would ever be. It's not a basic code repo manager feature, but there's a clear reason why they're focusing on one more than the other.
agreed. After a few years of this, I've given up hope of them focusing on the core project. They have basic usability errors in their merge request and approval flow that makes the product a pain. For example, in 3+ years of using the product, I still have no idea where to find all the merge requests where I am listed an an approver. Our slack channel is littered with folks re-asking people to review their code because there is no way to tell what you need to review.
But instead of focusing on the core features, here's probably what they will launch instead:
- a slack like chat app
- a trello like app
- a yammer like app
- redesigning the left nav once again
- adding even more UI clutter in the merge request box because they still haven't jammed enough crap in there
> I still have no idea where to find all the merge requests where I am listed an an approver.
Click this image in the top right-hand side: https://i.imgur.com/vWOxECQ.png
Approver, not assignee. You can be an approver without being assigned the MR.
Ah, that's something else indeed. I guess it does show up in the TODO list which is the button to the right of the one I linked earlier, but there's a lot of other cruft in there, including already merged MRs.
> but there's a lot of other cruft in there
The ToDos is a sort of inbox of actionables. We don't use approvers because we use assignees for MRs but here you'll get anything that requires (or may require) some action on your part, like mentions, assignments, CI job failures you're responsible of... ToDos get automatically "done" when you act, such as replying to a mention. Alternatively you can manually mark some issues as "done" or "to do". I like this workflow personally use them to great effect by practicing a form of Inbox Zero, and combined with the personal issues and MR lists they give me a good picture of what I have to do.
> ToDos get automatically "done" when you act
Well, that's not flawless. I never use the TODOs view, because it's full of items like this:
https://screenshots.firefox.com/wxy2llOZM5g0HWre/gitlab.com
In other words, there's a number of issues assigned to me listed there, even though they're closed. There's also a few mentions that I don't otherwise interact with (I've seen them in my email and that's that), so I'd have to manually mark those as Done in the GitLab interface after reading them in my email.
We completely agree with you here. We want TODO to be meaningful and useful to everyone. The UX team is working through an exploration issue to address this, we would love to hear your thoughts on the issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/43474
Thanks for your feedback. I've just taken on merge requests as part of my responsibilities, and hope to schedule this soon!
Here's a link to the issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/1951
I'll
They've already done the first 2. Though the chat app part was done by someone else.
> - a slack like chat app
They have, the Omnibus variant as well as the gitlab-ce docker container based on it includes Mattermost with integration. Just awesome, actually.
Paying customers.
Specifically, the person who signs off on Gitlab at a company is generally some kind of project manager so they value project management features.
All the extra features is the main selling point of GitLab. It's the reason you use it over GitHub because GitLab is more than just repo hosting and issue tracking.
That, and the fact that you can self-host
You can self-host GitHub, too: https://enterprise.github.com/home
You can, at entreprise prices indeed. Which is out of reach for most SMEs out there. This is IMHO a llarg part of what made Gitlab successful.
The price is roughly $21 per user per month, which isn't really all that enterprisey, given you have at least 10 users, that is.
I don't know exactly how GitHub Enterprise and the GitLab Community Edition compare in that regard but aspects such as usability, maintainability and updatability are much more important than saving $21 per user per month.
So, yes if your company has a lot fewer than 10 Git users GitLab probably is the best option. In every other case, it depends and the pricing advantage becomes less pronounced.
Sure, Github definitely has worth. I use both myself.
But for a petty price, Gitlab comes with a Kanban board, a release management system, a (free) CI tool, and all of the newer features I don't have experience with ( the whole Kubernetes integration lately? ). (So no need for paid travis, Asana, Jira, ....).
Adding to that that most cloud providers offer ready to use images with Gitlab installed, I understand what it becomes such a 'default choice' for new installs lately.
Compare apples to apples, at least. The paid GutLab plans are as expensive or more than GitHub. And they keep raising their prices too cuz they aren’t making enough money to survive. The big difference for us (Apple) is performance and reliability. GitLab isn’t reliable and GitHub Enterprise is rock solid with whatever we throw at it. That’s better than a bunch of features (to my team, at least).
GitLab the company was cash flow profitable in the first quarter, with 90% margins and doubling incremental revenue (IACV) YoY. We're very much default alive.
Our biggest customer installation had a serious problem in 2015 and we addressed it. We have customers switching from GHE because of the reliability of GitLab self hosted. There are problems on GitLab.com, we made solving that harder because we insist on running the same code our customers are running, so we'll never have a repeat of 2015.
We would love to get in touch to discuss any performance problems you're still having.
> The big difference for us (---) is performance and reliability.
If that's the name of your employer, bear in mind that you can get into massive hot water for using it to endorse third-party products without authorization.
Ive read about them using both systems. Seems like teams have flexibility to choose what they want. As they should. And some prefer GitLab.
Cool to hear that Apple uses Github. I don't think we disagree. Gitlab has had reliability issues the last months/years. Probably in part due to their rapid growth. And I still prefer the stability of the Github infrastructure compared to gitlab.com.
I was trying to say that, in my experience, Gitlab has become the defacto VCS tool for new/small companies that want something self-hosted.
What's interesting is, I do see the trend slightly change the last year, as Gitlab becomes heavier and people switching to gogs.
In the end there is probably enough space for all depending on your needs.
GitHub enterprise is a walled garden: you can’t use it to host open source software.
Github has Enterprise edition for self-hosting: https://enterprise.github.com/home
At $2,500 per 10 users / year [1], vs the GitLab Community Edition download at https://gitlab.com/gitlab-org/gitlab-ce/ (it looks like a MIT license)
Maybe it's worth the price. Did anybody used both of them and is willing to tell us how they compare?
[1] https://enterprise.github.com/features#pricing
Ultimately, I think, Git is a PM tool. Its benefits are __not__ exclusive to programming / code. The future for Git is much broader. GitLab is likely positioning, leading, and leaning into that future.
Git has never been anything other than a project management tool - who do you think had to organize code changes in the 1980s?
Then? Those (other) tools? That workflow? It was for version control.
Today? The needs are different, and Git needs a better wrapper to do that. Thus, GL's emphasis on less code-centric (more PM-y) features.
In all the scenarios I've been involved in implementing a new version control solution, there are already existing project management and issue tracking solutions in place, and appearing to want to replace them is a hurdle to be overcome rather than selling point. We use Gitlab, and the CI and Issue tracking features all sit idle, but better integration with Jira would be valuable, cause ain't no way we're switching issue trackers.
Replying to myself. Oh, I'm not saying it's wrong, I'm just pointing out how the incentives line up with the outcomes :-)
GitLab has moved past being a "a code repo manager" and is creating a tool to manage the entire SDLC. My reaction to this is the opposite of yours. Adopting it has already allowed us to get rid of Jenkins (shudder), and will soon allow us to replace Jira as well. Your wishlist is reasonable enough but I like the direction they are going.
I wish I could build my .NET code in Gitlab which runs exclusively on *nix.
If you self host, you can install a runner on a windows host and use the powershell executor
Exactly. We support Windows runners for several tools and they work fine. Our developers delight in adopting obscure build tools and we have been able to support them all. On a humorous note, when I told my management that we had updated our process to support "yarn" and "gulp" they wondered if I was just making stuff up.
Can't you do Windows runners even on cloud? I thought there was a callout on their pricing that said that your custom runners don't count toward usage metrics.
You can connect Windows runners to the cloud. I made an example project here:
https://gitlab.com/allthethings/allthethings.gitlab.io
Agreed that GitLab could really do with some development of boring, unsexy, wholly necessary features now that they're seeing some well-earned adoption. Please, please, please add batch review.
Add to that list that big diffs with many files (which are a bad practice, but do happen) causes the entire browser tab to freeze up.
I LOVE that they are providing alternatives to ugly and slow Jenkins. Gitlab is so much nicer!
Hi. Co-founder of CloudBees here (and sometimes contributor to the Jenkins project). I have described the UI as far worse words than that myself, but things are changing:
- Reboot the UI (it isn't just changing existing, but replacing): https://jenkins.io/projects/blueocean/
- Getting rid of version numbers and updates, and fiddling with plugins by hand: https://jenkins.io/blog/2018/04/06/jenkins-essentials/ (make it ever green, like browsers)
- Jenkins X - which is really about how you build apps on Kubernetes: https://jenkins-x.io
- We also have https://CodeShip.com - for those that don't need the on-prem/self hosting flexibility/extensibility and want things to work as a service.
Its great to see so much activity in CI/CD these days, really cool to see. Hopefully if you run into Jenkins again one day in the future it wont be the one you have a bad memory of.
We are paying for gitlab, and the only think I'd like to see from this list is rebase before merge...
I think gitlab are doing a pretty good job with their product.
Currently GitLab lavks global/group level setting to connect a k8s cluster, so we have to set it up one by one for each project hosted on it.
When you pick tabs over spaces you have to live with the fact that many people will pick a width different from yours. :)
You can use git for these "core" features?
Batching code review comments is a feature of the code review tool
It's definitely not exclusive to gitlab/hub/whatever. You've been able to do this on mailing lists when reviewing a patch since, well, ever since email was a thing.
Plus one for configurable tab width, jfc.
>GitLab has memory leaks. These memory leaks manifest themselves in long-running processes, such as Unicorn workers. (The Unicorn master process is not known to leak memory, probably because it does not handle user requests.)
>To make these memory leaks manageable, GitLab comes with the unicorn-worker-killer gem. This gem monkey-patches the Unicorn workers to do a memory self-check after every 16 requests. If the memory of the Unicorn worker exceeds a pre-set limit then the worker process exits. *
I know this is a Rails issue, but I cannot believe this is still a problem. I remember when the RoR folks blamed the Rails memory leaks on Zed, and Mongrel, more than a decade ago. They were obviously incorrect. Did the community simply give up on fixing the problem?
* https://docs.gitlab.com/ee/administration/operations/unicorn...
I have no idea about either ruby or rails but since ruby is a managed language this kind of issues seem like they should be pretty easy to debug ?
After all, if the gc is not freeing the memory then it must know a reachable path to it so the blame should be easy to assign.
Does ruby not have any good heap profiling tool ?
I don't know anything about Rails but most memory leaks in managed languages are stuff like lists growing infinitely large, parts of them pointing to data that is no longer relevant. Think badly implemented caches, stuff like that.
If you have enough not-perfectly-cleanly-separated layers of data management interacting, then this gets hard to debug pretty fast.
Not when you have GC graphical debuggers like Java,.NET and JavaScript do.
Why are they still using unicorn over Puma? That’s one question. Using unicorn killer is the sign of some bad engineering. It’s the equivalent of restarting your server every hour.
We are planning to start using multi threading and Puma so we can reduce the memory requirements of GitLab. The last time we shipped that we had to revert due to hard to diagnose errors. We're taking a more incremental approach now.
Were you under the impression that Rails has a functioning dev community?
I am very familiar with the rubyverse, and boy do I got news for you.
Rails is to Ruby as the Big Dig is to Boston.
But it's hard to get Rails devs to admit it. They know it, of course. They live it. They breathe bad code, they exist as extensions of a philosophy that has failed it's way to the top.
I used to think Zed was a dramatic weenie. Then I got a bit deeper in Rails to learn how to pursue better exploits. And deeper. And deeper. And finally I just hit a point where I just wasn't willing to work on RoR-related gigs.
Convention over configuration is one of those ideas that goes great on paper. And then you start in on some buzzwords and fancy lingo, it's the bread and butter of selling to project managers. But there is a point where CoC breaks down at a technical level, and that point is literally the first moment you come across something difficult to express
Rails is weak in doing things ANY other way than the Rails way, and what developers do (and it's not their fault) is using their creativity and ingenuity to solve the problem. I believe this is why metaprogramming in Ruby has such a vocal backing, because there are millions of shims holding up millions of Rails' shitty choices that depend on method_missing fuckery or string-based define_method gadgets. In the spirit of what it means to solve hacker-ish problems, it's great fun to program like that for a while, and then a year or two down the line you look at that shit and it can really break you down. Good developers mistake themselves for bad developers because of this, to be honest.
Zed's probably had the idea to write an entire book of how insanely FUCKED Rails actually is, but to make the book plausibly thorough would mean a human being being exposed to far more stupidity than modern science can safely treat for. It'd be dangerous to have that much stupid intake just for a book.
That unicorn-worker-killer gem is a perfect caricature of the kinda problem-solving you run into with Rails. Let it die a horrible death, restart that shit with some logic to let it keep dying predictably.
That technique, multiplied by every component in the system, multiplied by every developer on the team, multiplied by MVC requiring developers to have to know too broadly the system they're working on, multiplied by however many years and Rails versions the project has somehow survived, you approach something I can only imagine is quite similar to what hell must be.
I spent 3 years working on a Rails app and it was enough to make me swear off Rails for the rest of my life. I think the Rails dev community has good intentions, and the design of Rails is actually pretty nice. The problem in my opinion is more with Ruby, and human laziness. Ruby lets programmers do absolutely anything they can think of no matter how unexpected or un-intuitive it will be to their colleagues. Combined with the rigid conventions of Rails' design, this inevitably leads to a maintenance disaster with people, like you say, getting too creative.
Refactoring a large Ruby on Rails codebase is basically impossible. There's no compiler to help you along; hell the code is evaluated lazily. So instead of refactoring, people monkey-patch their problems away. It's horrible, really really horrible.
I'm now getting flashbacks to trying to understand how files get loaded in that codebase... I need a drink
I don't completely get this sentiment. Is refactoring a big java program easy? Yes, you will get nice hints from the IDE, but who knows how many things you screwed in the process of refactoring that the compiler isn't telling you about? Especially when it's not your code, when the person who wrote it isn't there, when you're not 100% what the code is actually doing, when it's undocumented and the intent isn't clear etc etc. Or worse when there aren't any tests which I'm sure happens a lot in java land. Why would this be specific to Rails? You're making it sound as if the twitter team can rewrite their app in 2 days because of 'compiler'. Big complex projects are big and complex. In Java / C# / Scala they're even bigger because of types, interfaces, traits and other kind of verbosity. It makes it harder to wrap your mind around the application in the first place.
It seems like you’re taking this a bit further than the parent comment said - e.g. there’s no claim that any major piece of software can be refactored that quickly, however the general process can be made simpler and safer with decent static tooling.
As a concrete example on a small scale of something common such as renaming a model field name. Given that ActiveRecord reflects the database and generates the methods dynamically there’s pretty much no good way to refactor that field easily. It requires a lot of manual searching/filtering to find possible usages and then time on that to ensure it’s not a shared name on a different object type. From what I’ve seen in many code bases it ends up manifesting as `delegate` usage and often just expands the API exposed by the model.
Compare that to something compiled, or even something like python that doesn’t encourage meta too much, and you can pretty much find all symbol usages with whatever intellisense engine you prefer (ctags, JetBrains, jedi, ...)
I agree static analysis can help. Specifically for changing column names it just doesnt really happen that often in most projects I worked on...so I never really thought it to be a big deal.
Then you're lucky. I specialize in refactoring and reorganizing extremely messy and large / complex applications. And Rails is my fucking nightmare. Especially when untangling ActiveRecord callbacks, fat controllers, convention over configuration, magic method, and database changes.
I would give a kidney to have static compilation in rails when refactoring.
I think linters and IDEs will help with that.i already see big improvements in js linters
That goes to my point, rails doesn't have the symbols in code for the editor to use to refactor because they are added at runtime dynamically when ActiveRecord reflects the database. You can have a full model that just has `class User < ActiveRecord::Base; end` that has 15 fields on it, none of which are in the code.
> They know it, of course. They live it. They breathe bad code, they exist as extensions of a philosophy that has failed it's way to the top
I think this is a dangerous line of thinking. This crosses the line of being productively critical of a language or a framework into actually attacking people.
By promoting this line of thinking, you increase the tolerance of this kind of attack.
People arrive at their personal choice of language and framework as a function of their environment, their education, their first job, what's popular at the time, and myriad of other factors.
I am sure you have preferences for languages and frameworks, and I'm sure there are other people who don't agree with them. Do you want those people giving you reasoned arguments about why you should change your preferences or, do what you did, make allusions that you are so irredeemably stupid that you physically exhale shoddy code?
My day job is working on Rails apps (most of the time anyway -- we have a diverse infrastructure). I'm not a big fan of Rails architecture and struggle to communicate to others why I think the "Rails Way" is not necessarily a good way. But these things are hard to swallow, especially if you haven't seen anything else before.
However, I have a special dislike for "convention over configuration". What that really means is: You must write code my style. As there is no configuration, it will be difficult to discover what that means by reading the code. You must study and memorise the one true way. If you deviate from it, strange things will probably happen and it will be your fault for not doing it my way.
To be fair, Rails documentation is really very good. Also, this is a selling point for the framework. If you give no choices then everybody must do it the same way. Even if that way is stupid. You can hire a whole bunch of people who "know rails" and they can struggle along and make progress. You don't have to trust them with decisions because the important decisions were already made for them.
I've had a wide and varied career before doing this work. It's hard for me accept "because it's the Rails Way" to questions like "Why are we doing this when it is causing problems?" I don't mind people making mistakes as long as it is not a thoughtless mistake. "I thought this would work, but I was wrong", is a wonderful sentence in my book. Unfortunately that's the kind of action that many programmers are dissuaded from taking -- instead they are encouraged to do it the "Rails Way".
Lots of beginning programmers also prefer it this way. When you are first starting out (and... well... even when you've been doing it for a couple of decades) it's hard to know which way is better. You might even have a preference, but then struggle greatly when someone asks "Why is that better". Especially beginning programmers often get stuck without knowing any way to accomplish something. In those cases, the "Rails Way" is extremely comforting. 1) It's a way. 2) It will probably work (at least grossly) 3) Famous people say it's good, so it's very, very comforting to agree. People entrenched in the community reinforce each other until it seems practically impossible that there might be a better way. But they may not have looked.
Of course Rails is not the only "Way" out there that espouses these ideas. It's just a currently popular one. What's really at fault is the "convention over configuration" attitude -- Don't think; just do it my way. I hate that.
Still lots of love for Rails in the HN community on this recent thread: https://news.ycombinator.com/item?id=17355187
Rails is popular as startups because it's easy to pick up as a first language meaning the labor market was cheap and flooded with coding boot camp grads. Startups love cheap labor and they don't really care if things are built to last or will scale. They only care about it lasting until their next funding round or (hopefully) their exit.
Rails Devs are well compensated...where are you getting this from? Yes rails is more suitable for rapid development than spring, and easier to teach and learn. How is that bad though
I love Rails for certain projects, but it's definitely true that at a certain point things start to break down. Maintaining a large complex application with Rails is not fun at all. ActiveRecord is amazing, until it's not.
IMO, you can still learn tons of great practices with Rails, and for certain projects I still think it's a great choice... But you have to know when to drop it and move on to more robust solutions.
Like most engineering tools, it makes certain tradeoffs, and you have to know how to pick the right one for your job.
At certain point everything starts to break down no matter the stack.
You're absolutely right, you're just completely ignoring context. Some things break down a lot sooner. Eating or drinking too much of anything can kill you, even water. But drinking acid will get you there a whole lot faster. Rails is the acid of the programming world.
After many years of working on a variety of Rails projects, I've pretty much come to the same conclusion and, if you look at it another way, it's the same conclusion no matter what you work with.
Rails is incredibly effective for solving the problems that existed at the time it was conceived. CRUD websites, rapid prototypes, things that aren't incredibly complex. Not an exhaustive list, but that's what I reach out to Rails for now.
Once you get past that certain point, not only does the framework fail to offer a convention for the problem you might face, but it also requires a mature team of developers to guide things forward from that point on, and really think about how to build something that Rails itself has no decent answer for. That solution might be to break out of Rails, or switch to raw SQL queries, or to proxy to services that can handle the task better. It's almost never a good idea to double down on the convention at that point.
I am no expert at all (a current comp sci student), but when I read this line in the unicorn-killer explanation I lol'd:
> This is a robust way to handle memory leaks
Seriously wow.
Not to detract from the Rails situation because I largely agree with it, but there are also issues with Ruby's memory management, as some memory just can't be reclaimed. Rebuilding Ruby with jemalloc helped in mitigating rampant memory fragmentation for our loads and use cases, but things can only go so far regarding how things are managed. At some point the processes need recycling, so yes, most literally, regularly reaping the workers is most literally a robust way to perform an OS-level sort of GC, as in you're 100% sure it works with any reliability, and even though it may hurt some theoretical sensibilities this is a very hands-on, practical solution.
You are blaming Ruby? Plenty of major orgs running Ruby at scale aren’t resorting to restarting the server to solve memory leaks.
It is a practical hands-on solution. However it’s also bad engineering. I too have used unicorn-killer and it was always the result of trying to make bad code not crash our servers. It is a lazy hack solution that I used because it was easy and at the time didn’t know enough to fix the actual issues. I was inexperienced. No disrespect intended but with the suggestion that essentially restarting the server is a robust strategy against memory leaks, it’s kind of hard to be confident of the technical robustness of the platform, especially at scale.
I can guarantee that Github isn’t using unicorn-killer nor blaming Ruby for performance issues.
Agreed. As someone who has worked with Rails over the past 9 years, the only time unicorn-killer is generally used is to save an application from very bad engineering. That’s it. That’s the only reason to ever use it. No serious (or even not-so-serious) production app should be using unicorn-killer as a strategy. Ridiculous fail. Rather than releasing shiny new stuff, it might be wise to fix the core issues with the stability of the system first. Using New Relic or Skylight should at least help narrow down where the memory leak originates.
I know we are supposed to be “Hurray Gitlab! Open core!” but it feels like GitLab support around here is contrived and astroturffed, by GitLab insiders. Any company that actually claims unicorn killer is a robust way to handle memory leaks has some extremely incompetent technical leadership. The robust way is to not to have memory leaks! Essentially restarting your servers all the time (which is what unicorn killer practically does) is a ridiculous way to handle memory leaks.
I feel they're making it harder to review a merge request with multiple commits. It used to be able to click on a commit and get succinct view of the actual commit with title and message. Now days after clicking on a commit, you have to scroll down and skip a lot of irrelevant information to find the actual commit content - and gitlab by default hides the commmit message! This makes it very cumbersome to review a MR with many commits, and also harder to train new developers to learn the advantages of making good commits.
Being able to review per commit in a merge request was a major reason for my company to choose gitlab back in the day. A merge request consists of a series of commits, each doing a single change (basically the same way linux's patch series works: https://www.kernel.org/doc/html/v4.16/process/submitting-pat...).
I'm hoping gitlab will improve the experience in the future for us that want patch series style merge requests, but I'm worried that gerrit style development is winning where the result of each merge request is supposed to be just a single squashed commit.
Thanks for the feedback gorset. I'm curious to dig a little deeper.
With the irrelevant information, you mean the top part of the merge requests (ie description, CI status, etc)?
And as far as I can see, in the current version, we only hide the body part of the commit message.
I think we can make the experience better by autoscrolling down once you click on a commit in a merge request. I've made an issue [0].
I'm not sure about showing the full commit message. Many would argue that only the first line summary is crucial to show, which is what we do now. But I'm happy to discuss.
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/48328
Thanks for the quick follow-up!
This might be a difference in expectations, where we are talking about two styles of merge requests. I believe they can be both supported well by gitlab (in fact, I consider gitlab to be the best review tool out there because it has support for both styles).
## Gerrit style MR
Mostly a merge request with a single commit. All relevant information is placed in MR title/description. If there are more than one commits, they are usually added to review the first commit based on review feedback or problems detected by CI. The commits are often squashed before merge to master, so the individual commit messages are secondary to the MR title/description.
## Patch series style MR
A merge requests with multiple commits, each containing a single logical change. The MR title/description only contains high level information/summary - more detailed description is found in the commits.
If serious problems are found either by CI or reviewer, the developer often amends the commits rather than push new commits on top. The reason why is that each commit should be as complete as possible, which helps reviewing, git bisect and keeping a good git log history.
This style requires more upfront work by the developer, but the advantage is that reviewing becomes easier. Instead of reviewing a large diff with many different changes, the reviewer can look at a single commit at a time. Some types of changes such as refactor, reformat can quickly be verified and reviewed because they are not making any semantics changes. A commit containing a bug fix is much quicker to review if there are no refactoring, reformating or other semantic changes in the same diff.
Good commits should also have good commit messages, which describes what, why and why like /this/. Just as important, this information should be easily available when reviewing the merge request. It should be easy to iterate through all the commits in a merge request, reviewing both the commit message and the commit diff for each commit.
With the latest changes of gitlab, I feel it's being optimized for Gerrit style merge requests, in which case your comment make sense that you're not sure about showing the full commit message. However, for me this is a major step back since we do patch series style merge requests where each commit is often reviewed individually.
Thanks gorset for the great response and the new insight you gave me into this. I now understand what you mean and see how the changes have negatively affect patch-series style MRs.
I created an issue on this and I encourage you to contribute there as well: https://gitlab.com/gitlab-org/gitlab-ce/issues/48334
We're not fans of adding additional configuration, but I can imagine we store e.g. what the last state was that you left commit message in, as to not have to unfold it every time. I'm sure you have further thoughts on improvements that can be made.
The full commit message is just as crucial as the first line. Take for example a recent commit to the OBS project on GitHub: https://github.com/obsproject/obs-studio/commit/26d5560da3b7...
The exact commit is as follows:
Without the full message, I would not know what this commit brought until the changelog is updated on release. Now I know what to expect and why is was committed. In a merge request, I would like to see the same level of reasoning. For example, if there was a new commit pushed in a MR that I already saw that changed one line, I would prefer to see reasoning behind the change.This is all personal preference though...
The commit message is the most important fricking part. It explains the why.
We've been paying for GitLab for about a year now, and it's mostly been a good experience. There have been three things that seem to come up weekly for us:
1. Lack of traceability/auditability. We're in healthcare, and have a regulatory burden that requires versioning of basically everything. GitLab does this for code and wikis (thanks to git itself) but not for issues, merge requests, comments, etc. I've ended up building a service that just ingests the webhooks for these to store them away, which feels ridiculous. Since the webhooks for comments doesn't get triggered on update, I even have a TRIGGER shimmed into GitLab's postgres DB. Ech.
2. There's no concept of a bot user, so every integration we want to do is against a single account/identity, in part because...
3. The pricing of Ultimate feels ridiculous, and that's the only way to get something as fundamental as epics. $1000+ a year for every employee?
[edit] $1000/mo -> $1000/yr. (per month would have been even more way cray)
> $1000 a month for every employee?
Typo? Pricing page [1] lists it at $99/mo
[1] https://about.gitlab.com/pricing/
Thanks, edited!
Thanks for the feedback. To address each point:
1. I'd love to see everything versioned in GitLab. We're working on the issue descriptions, but I agree we should move toward versioning everything. There's an epic here [0], that we will be filling out with more issues to address what we haven't yet. Feel free to leave feedback there as well.
2. Most integrations are against projects, groups or instances. For those that require an acting agent, I recommend just creating a normal account for that and call it bot. I think it makes sense for us to have some sort of permanent solution for bots [1]. In the meantime, I propose you talk with our sales team about that. I'm sure they're willing to be flexible.
3. We believe the pricing for Ultimate is fair, given the broad range of tools GitLab replaces, from project management, to CI, to security, licensing and container management tools. That said, we're aware that it's challenging to see the value for every single user. With this release we're taking a step that hopefully helps out, by making guest users free for Ultimate [2]. We welcome further feedback on how we can make GitLab even more accessible to everyone in the organisation.
[0]: https://gitlab.com/groups/gitlab-org/-/epics/237
[1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/6600
[2]: https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#un...
About 1: take a look at sit https://github.com/sit-fyi/sit and git-dit https://github.com/neithernut/git-dit
It would be nice to work with an existing project than roll your own.
Thanks for the suggestion.
As the author of one of these projects (sit.fyi), I'll be happy to show and explain its philosophy & benefits (some are quite interesting and yet to be possible in conventional options). I think that discussion can be of value to all. Feel free to reach me at me-at-yrashk.com if interested!
You might want to check RhodeCode at some point. Because our main customers are in Healthcare/Insurance/Automotive, and all those industries require strong auditability. We built very advanced audi logs capabilities, every permissions change, every comment, is traced with IP user and old data is saved.
In addition to [0], to version-track issue/mr descriptions that was already referenced earlier (within an epic), we also have [1] open, to do the same for comments. Please feel free to comment more there!
[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/15597
[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/3706
The audit logging capability offered by GitHub Enterprise are very comprehensive. Useful for compliance scenarios like this.
If you export and parse the logs (which you should). But out of the box all kinds of write level or auth interactions aren’t exposed in the audit log search UI.
I haven't checked out v11 yet, but since it's not yet mentioned I assume the admin UX hasn't been addressed. Of all the tools I have admin on, Gitlab's admin UI (spread out across multiple sections) is perhaps the most sprawling and confusing. For example, there are two "repository" sections in each repo (one top level, one under settings) - in one you can perform repository admin such as branch management, and in another you can configure things like deploy keys. The groups/users/repo setup is another example of a clunky workflow - functional, but too many steps, and stitched together CRUD UIs. I get the feeling no product manager has sat down to address admin cohesively for a number of years, but rather that it has just grown organically.
My other big wish for the product is better CI. Gitlab certainly makes Travis unnecessary, but it doesn't scratch the surface of the functionality that Jenkins provides via the plugin ecosystem. Yes Jenkins is janky (although can be made to look nice enough via themes) - but Gitlab doesn't even address parsing xunit results and displaying trends in a project centric reporting location (https://gitlab.com/gitlab-org/gitlab-ce/issues/17081), instead steering you towards build centric "pages". Get the reporting built out (and also allow it to natively consume/parse/understand output from major testing & static analysis frameworks), and it would be a more compelling alternative. Nobody wants to look at hundreds or thousands of lines of build/test output - the CI tool should summarize the reasons for success or failure.
Finally, we're having to run our self-hosted Gitlab on an absurdly large EC2 instance (8 cores, 32GBs). Occasionally we'll have a dozen people converge on a single important PR for review, and before upgrading to our current server this type of event would often bring our instance to its knees. Language choice may be a significant contributor to this -- rewriting major parts of the backend in Go or some JVM language would probably be a good product goal.
You're right. The UX in GitLab's admin settings has lots of room for improvement. The good news here is that we now have a product manager devoted to this area, and have a number of improvements scheduled here that should help. A few I'm excited for that we're hoping to schedule for 11.2:
- Splitting the admin settings into multiple sub-pages to make it easier to visually parse (https://gitlab.com/gitlab-org/gitlab-ce/issues/44998)
- Adding search for settings pages (https://gitlab.com/gitlab-org/gitlab-ce/issues/41112)
- Prioritizing content on settings pages (https://gitlab.com/gitlab-org/gitlab-ce/issues/47405)
The UX team has an epic on these improvements (https://gitlab.com/groups/gitlab-org/-/epics/203), grateful for any feedback on specific issues. Thanks for pushing us here to improve.
Great! Thank you for the response. I'm glad to see the momentum you have.
Thank you for the feedback! Keep it coming as we improve the admin area :)
Thanks for caring. I asked UX to respond to the admin UX concerns. We're planning a first iteration for xunit in 11.2 https://gitlab.com/gitlab-org/gitlab-ce/issues/17081#note_83...
GitLab now runs a copy of the rails stack under Gitaly because the git Go libraries don't support everything GitLab needs. So ironically moving to Go caused GitLab to use more memory. This will be fixed in Gitaly 1.1. There is no due date for that.
It might be interesting to someone that GitLab is not seem to be compliant with current European data regulations (GDPR), it is worth reading their terms and privacy statements [1][2]. E.g. even self hosted GitLab phones home in opt-out fashion.
GitLab collects information about usage from each self-hosted GitLab instance (Community Edition and Enterprise Edition) through a usage ping. The usage ping sends a payload containing data such as total number of projects and pipelines, as well as license information and hostname to GitLab.
...
The information from the usage ping is not anonymous, it is linked to the hostname of the instance [3]
...
The documentation is a merge request [4]
This MR loads the EE usage ping asynchronously on the admin application settings page and now includes the counts of the following items:
Comments Groups Users Projects Issues Labels CI builds Snippets Milestones Todos Pushes Merge requests Environments Triggers Deploy keys Pages Project Services Issue Boards CI Runners Deployments Geo Nodes LDAP Groups LDAP Keys LDAP Users LFS objects Protected branches Releases Remote mirrors Web hooks
[1]https://about.gitlab.com/privacy/ [2]https://about.gitlab.com/terms/ [3]https://docs.gitlab.com/ee/user/admin_area/settings/usage_st... [4]https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/735
Remember that the GDPR only applies to personal data. That is defined rather broadly, but it still might not apply to all the information you've mentioned.
In the EU IP alone could be considered PII, it would seem logical that hostnames are too, but I never saw it spelled out. The counters are sent in combination with these identifiers. The summary above is compiled from GitLabs own sources. Most probably don't care but some might.
> In the EU IP alone could be considered PII
that statement is wrong. first of all IP Addresses are only PII if you store them to identify users, means that if you are user table has an ip_address field, it is, however... if you store all ip's accessing your service in a database to find malicious logins it isn't. so basically the statement is, it depends. the connection of user to ip makes it PII.
I think we agree context is important. However GitLab is collecting IPs in combination with hostnames, not to mention the rest of the traffic that could easily be used to fingerprint users.
GitLab obtains affirmative consent to its use of personal data under privacy policy, plus users also have the ability to opt out if they wish revoke their acceptance.
GitLab offers a blanket checkbox on signup with a bunch of legalese, there is no fine grained opt-in to the data collected. Worse, as you said, it is all opt-out.
Is there any timeline for monorepo support? The ticket has been sitting in the backlog and every once and a while I get an email when someone bumps it. I with this feature got some love so service oriented architectues were more manageable
Can you link to the issue? We're working on multiple things that might help monorepos.
Hey sytse. This is the issue number [0]. There's a few people at the company I'm working at who have been pushing really hard to move away from GitLab to GitHub. One of their main issues, from what I can tell, stem from this issue and getting some integrated support for monorepos. I'm very glad you're working on the features monorepos require.
Aside from monorepos there is one other small issue I have with GitLab. GitLab is perfectly well situated to completely take over the software development planning, warehousing, deployment, and testing. Documentation is really the last front. If GitLab wikis were as powerful as Confluence I would be very happy because I'd never need to use that terrible bloated site ever again. I've been pushing for us to switch to GitLab wikis for a while but 2 coworkers keep saying that "it is not good for long-lived out-of-project documentation, it's not as searchable, you can't drag and drop for graphs, it's not as integrate, and it doesn't have as many features as Confluence".
I hope one day GitLab can be my one-stop-shop for everything.
Thank you very much for making such an amazing product.
[0] - https://gitlab.com/gitlab-org/gitlab-ce/issues/18157
Thanks for linking the issue. I'll discuss it with our product leaders.
Regarding the documentation we see many people switching to static websites generated with GitLab pages. This allows you to separate the change from the approval. Is this an option for you?
Personally I think that works and gives you all of the "edit-locally" benefits (Accessibility, hotkeys, versions, distributed/backed up etc). What that doesn't give you is a few other important features.
My coworkers are concerned with the following:
I agree that most of those are not in the wiki nor in GitLab pages.
For non developers you can make it easier to edit by linking the bottom of each page to the reposity. See our website or docs pages for an example of that.
When will it be possible to revert commits in non-master branches in the UI?
It already is? If I visit a single commit's page, in the Options drop-down on the top right-hand side I can click Revert, and a modal pops up asking me in which branch I want to revert that commit.
Yes there is that dropdown. But when you select your feature branch and click submit, some magic happens that does not do what you think it does.
Hmm, what magic is that? It appears to create a new branch with the revert, and create a merge request from that branch to the branch I select - which is what I expected. This is of course with "Start a new merge request with these changes" checked. When it's unchecked, I'd expect it to make the revert commit directly on that branch; is that not what happens?
I just checked, user Vinnl is correct that you can already do this for every commit, and targeting every branch.
linked merge requests would be my killer feature. VERY often we need to change multiple repositories at the same time. Like for example backend+frontend changes that's in different repositories. Having a linkage between them, that would make them be merged together would be awesome. And also prevent merge if one is "wip" or unresolved discussions etc...
We're working on this! We've wanted to explore this for some time; we're tentatively calling this a "super" MR and putting some design time into 11.2 to understand how this might work. Lots to think through here. Love to get your thoughts in the discussion so far: https://gitlab.com/gitlab-org/gitlab-ee/issues/3427
Cool stuff, way more advanced than I thought of. I don't have an account but might create one, on phone right now. But I drop my 2 cents here. I rather see a free version with a simple relationship between MRs. Basically;
Then building a more advanced version for EE.Another attempt at centralizing our data (+). It may be a great piece of software (or not, I don't know), but no thanks.
(+) by data I don't mean the repo itself, but all the data around it (issues, project management stuff, etc).
I mean, isn't it the whole idea(centralizing) so we can work together? And what do mean with 'our' who are you? Also are you aware you can have your own instance?
What’s wrong with having the issues, project management stuff, CI, etc in one place, as long as you control that place?
and as long as you are not forced to is the built-ins if you prefer (or are otherwise already committed/constrained to) something else.
Still can't upload more than one file at a time using the web interface.
> We’ve decided to rename the Master role to the Maintainer role. It removes the negative connotations that may be associated with the term “Master,”
Good lord...
I'm not offended at all by using the word "master" where it makes sense. However, as a role for users, is sounds sort of odd and a bit authoritarian. I think "maintainer" is a nicer choice regardless of any political-correctness driven reasoning.
If we're talking about user roles for users with the implicit implication that it indicates a position relative to others, I'd say "owner" is worse.
In this context, though, the subject is the repository, an inanimate piece of property, not any other user. In that context, I'd argue that both "owner" and "master" are descriptive and very difficult to interpret offensively unless you're going out of your way to interpret them as such.
There are subtle differences in connotation between "master" and "maintainer", too - think "king" and "steward", apologies to Tolkien - it's not like they're synonyms and a swap is just being done in-kind. I think there's actually a case to be made that "maintainer" is a better label for the role, given the existing context of a project maintainer being one who has administrative control over it (and the existing "owner" root role), but to change the label with the reasoning that "master is exclusive, so we picked up a thesaurus" isn't going to pass the sniff test for a lot of people. A slightly more tactful approach of "we decided this better describes the role as it already applies to modern team organization" would have worked just fine.
I don't agree with the reasoning around the usage of the Master, but I am happy with Maintainer which seems like a better word.
In databases master slave is replaced by primary secondary. I think being inclusive means removing obstacles you might not see yourself.
Being inclusive doesn't mean thinking up ways yourself or others might possibly ought to be offended and avoiding them.
This sort of overoptimistic "inclusiveness" is the kind of thing that makes the people who doubt much more certain of their skepticism and should be considered harmful.
I'd also argue that it's exclusive of people who dislike arbitrary impediments to their dev work. Words like master and slave have semantic meaning going back decades in computing. Avoiding their use introduces ambiguity and makes everyone's job harder. We should be striving to reduce the number of synonyms for things, not introducing more for questionable reasons.
> might possibly ought to be offended
Have you considered the possibility that people other than you do find the terms offensive, and have asked for them to be changed?
> This [...] is the kind of thing that makes the people who doubt much more certain of their skepticism and should be considered harmful.
Those of us who live in the US are painfully familiar with this line of thinking... "you better change your ways if you want to convince me about this whole human decency thing! I'm still on the fence about being an asshole, and it's all your fault".
Guess what, nobody cares about your skepticism, because you're not in a position to decide on this issue, thankfully. Nobody is trying to change your mind, either. All that we ask, as a society, is that you keep your intolerance within the scope of the law, and refrain from killing or beating people as a result of your bottled up anger and sense of entitlement.
>Have you considered the possibility that people other than you do find the terms offensive, and have asked for them to be changed?
I have considered it. I would indeed be eager to speak with someone who actually was offended by the term. That is not someone who is offended because they believe it might offend a third party, someone who themselves feel hurt by the prevalence of calling a computer a "slave" or a person a "master" in this context in a way they believe is _significant_ and _important_.
I would love to talk to such a person and understand their perspective, but the point I am trying to make is I seriously doubt such a person exists.
I would also like to know if such a person would also be offended by the word "robot" which is a loanword meaning literally 'slave' in Czech.
There is a rising problem in society of people who ally themselves with straw-men and make moral issues in support of dubious claims of oppression. To be fair, it isn't a new problem. Virtue signaling or boasting of one's own moral superiority by shaming others is as old as society. In the last century in America most of this was about being a good Christian. This century we're in a transition towards greater irrelevance of religion and conservative morals, with the new most popular moral boasting point being about who can be the best liberal.
My point is not that issues of tolerance do not exist in our society, it is that increasingly, many people talking the most about tolerance seem to be doing so to further their own feelings of moral superiority and to display that to their communities. There is a disconnect between their actions and actual empathy for real people they encounter.
That is, to come back to the original point, nowhere can I find evidence of this change being attributed to empathy towards a real person who experienced grief. Just a lot of talk about people expecting the change will make people they suppose to exist feel better. That sort of empathy for the strawman is harmful because 1) it distracts from actual issues and 2) it diminishes the position of people talking about actual issues.
Thanks for that reply. ️
> I think being inclusive means removing obstacles you might not see yourself.
Agreed, yet I'm kind of concerned about those context-free word readings and absolutisms, which can deviate into a form of thought policing, censorship, and sometimes, bigotry. While it is important to take care of the weight words carry and be humane and respectful, words do not make sense without a context thus I have no problem with a process being "slave", because it has a very precise meaning in CS/IT nowadays entirely remote to the origin and history of the word, and not entirely encapsulated by "secondary" which is somehow more fuzzy. By that metric we should probably soon stop killing processes (oh, my! parents killing their own children!) and having daemons and so on.
Trivia: for maximum shock value about how context shapes word meaning and your perception of it, in French the n-word means both "a person of African ascendance" and "ghostwriter", and for the latter synonyms fail to capture the essence of what a ghostwriter is. So, yes, "nègre" is definitely used without offense when the context of literature is made absolutely clear, although it is tentatively replaced by "prête-plume" or "écrivain fantôme".
Which makes zero sense with any product supporting more than one secondary.
Why? It makes perfect sense. It's not the primary. That's it. The master slave means the same thing. They are just labels in a replication state machine (or system), you need to know the precise meaning behind them anyway.
Maybe Leader Follower is the best (zookeeper and kafka uses it also usually any distributed system, that has dynamic election).
Kafka is multi master. All nodes are taking both reads and writes.
The topics are leader-follower though, no? (And that's the consistency unit, that matters.)
Stop being offended by software. It's electricity not a human.
I've seen master-replica being used a lot too
Or indeed obstacles that don't exist!
If words on a screen are obstacles, maybe software isn't for you.
There are people who have survived ACTUAL obstacles like slurs being shouted at them, growing up in bad neighborhoods, surviving inner-city schools, they've got REAL SHIT to work through, and they managed to become competent, effective developers despite all that.
At some point, most proponents of """inclusive""" pattersn are nitpickers that fragile non-hackers are glorifying as arbiters of social consciousness and morality. It's dysfunctional and dangerous to empower people in such a broken frame of mind.
From 2003:
"Los Angeles officials have asked that manufacturers, suppliers and contractors stop using the terms 'master' and 'slave' on computer equipment, saying such terms are unacceptable and offensive."
http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut/
We got extensive feedback regarding the `Master` title. Renaming it to `Maintainer` is a relatively cheap thing to do, strengthened by the fact that it's a better reflection of the permission level: this is what Maintainers of repos will typically have.
IMO Master makes sense. The Master user is in full control, there is no one higher than the master.
In GitLab the owner can do more than the master/maintainer.
Ah fair enough. The change makes sense then.
Not really, maintainer is a more vague term implying any level of access and authority. Plus its more letters to type out forever over and over because someone theoretically was crying over this.
I miss the days when software was judged by what it did and how fast it did it and names were funny and clever.
Master is probably the admin role with full privileges. No idea what a Maintainer is.
Unbeknownst to you, you nailed it, because the "full privileges" role is "Owner", not "Master". "Master" really is "Maintainer".
Master of Ceremony? Scrum Master? Master Chief? What are they on about?
Not to mention the default main branch of a git repo is master
Unlike the 'master'/'maintainer' role, the main branch does not directly correspond to a person.
A master/slave DB isn't a person either and look where that ended up.
Which no doubt comes from the term "master copy", which has a long established, and quite precise meaning. Choosing a different meaning arbitrarily(or actually, quite deliberately) is disingenuous at best.
Hg sensibly calls the default branch `default`.
Git sensibly calls the master branch `master`.
That's funny, because it's pretty common to set a 'dev' branch to default and reserve the master branch for production code.
We won't change that until git does. Of course you can customize your default branch.
Where is the slave
Try "main"
GitLab is about removing the needless ceremony to getting your application deployed.
slavery, jim crow. being called or calling someone else "master" feels deeply troubling to many people in the US, and likely around the world.
Calling someone master can deeply offend. Are we really at the point where we cannot distinguish between a human being and an incorporeal blob of computer code? Life is going to be really, unnecessarily challenging if you go through it bending over backwards to invent new ways to become upset.
All of you whiteys should go tell Q-Tip and Phife Dawg to stop calling themselves "MC", this is cracking me up
If I were a database, I would be more offended about being summed up as a cylinder icon, since I power all of the world's apps.
It's nice that this doesn't bother you, but if you're not going to learn about and respect how words make others feel, at least have the decency to keep your dismissal to yourself.
I find the highly negative labelling of people as "dismissive" to be offensive. I think you need to learn some respect and decency yourself.
I challenge you to actually find someone who is offended by how these words were being used, not offended on behalf of someone else, but themselves felt hurt by the usage.
He mustered all the courage he could, to post using a throwaway account :)
I'm sorry, but we are going to have to ask you to use "Good Deity..." as your politically correct ungendered exclamation henceforth.
(This should really not need a sarcasm disclaimer. But maybe it does.)
I can never tell what the HN community thinks of GitLab.
Either the entire thread is loves it (for the most part), or the entire thread hates it (for the most part).
shrugs
Can you link to a time where the majority of a thread has hated on Gitlab? Maybe the one where they don’t pay too much and have a scale based on location, but I might be forgetting the ratio of hating and that wasn’t a topic relevant to Gitlab as a software project.
Otherwise it’s usually at least some or majority love for Gitlab on HN.
I felt like this thread is way more negative than the others.
Most of the time, it is all love.
If you are using the Omnibus package on Ubuntu, don't upgrade! It just broke my instance. and can't find out what's wrong. Great features... It was a big mistake to trust GitLab, I already predicted they will have problems.
What is the output you get? Consider creating an issue here so we can help you debug: https://gitlab.com/gitlab-org/omnibus-gitlab/issues
Here we go: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3615
Try rebooting the server.
No, I'm not joking. I've had the omnibus package break my Gitlab as well and the bugs survived even full reconfigures and restarts. Rebooting the server fixed it even though it makes no sense.
Thanks for the tip, but this was one of the first things I tried beside
I'm pretty sure this doesn't happen on all Ubuntu installs. Maybe you have some custom stuff?
I don't think so. The problem was that unicorn was not listening on IPv4 by default, but it was before 11.0. Weird.