16 ms·

GitLab 11 released

229 points by markdog12 8y ago

throwaway20934 8y ago
> 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...
- artursapek 8y ago
  Master of Ceremony? Scrum Master? Master Chief? What are they on about?
  - chinhodado 8y ago
    Not to mention the default main branch of a git repo is master
    - artursapek 8y ago
      git push origin unoffensive-term-for-dominant-entity
      - martenb 8y ago
        Try "main"
    - sytse 8y ago
      We won't change that until git does. Of course you can customize your default branch.
    - tomjakubowski 8y ago
      Unlike the 'master'/'maintainer' role, the main branch does not directly correspond to a person.
      - sieabahlpark 8y ago
        A master/slave DB isn't a person either and look where that ended up.
    - mappu 8y ago
      Hg sensibly calls the default branch `default`.
      - Qwertie 8y ago
        Git sensibly calls the master branch `master`.
      - BigJono 8y ago
        That's funny, because it's pretty common to set a 'dev' branch to default and reserve the master branch for production code.
    - berti 8y ago
      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.
    - NicoJuicy 8y ago
      Where is the slave
  - sytse 8y ago
    GitLab is about removing the needless ceremony to getting your application deployed.
  - diN0bot 8y ago
    slavery, jim crow. being called or calling someone else "master" feels deeply troubling to many people in the US, and likely around the world.
    - artursapek 8y ago
      All of you whiteys should go tell Q-Tip and Phife Dawg to stop calling themselves "MC", this is cracking me up
    - hyperbovine 8y ago
      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.
- diN0bot 8y ago
  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.
  - oblio 8y ago
    He mustered all the courage he could, to post using a throwaway account :)
  - colechristensen 8y ago
    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.
  - BigJono 8y ago
    I find the highly negative labelling of people as "dismissive" to be offensive. I think you need to learn some respect and decency yourself.
- sytse 8y ago
  In databases master slave is replaced by primary secondary. I think being inclusive means removing obstacles you might not see yourself.
  - deleted 8y ago
    [deleted]
  - qop 8y ago
    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.
  - colechristensen 8y ago
    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.
    - zapita 8y ago
      > 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.
- freditup 8y ago
  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.
  - cheald 8y ago
    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.
  - kochthesecond 8y ago
    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.
- voxadam 8y ago
  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/ http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut/
- sbr464 8y ago
  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.
- cup-of-tea 8y ago
  I miss the days when software was judged by what it did and how fast it did it and names were funny and clever.
- DoreenMichele 8y ago
  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.)
- user5994461 8y ago
  Master is probably the admin role with full privileges. No idea what a Maintainer is.
  - lloeki 8y ago
    Unbeknownst to you, you nailed it, because the "full privileges" role is "Owner", not "Master". "Master" really is "Maintainer".
- jobvandervoort 8y ago
  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.
  - Qwertie 8y ago
    IMO Master makes sense. The Master user is in full control, there is no one higher than the master.
    - sytse 8y ago
      In GitLab the owner can do more than the master/maintainer.
      - Qwertie 8y ago
        Ah fair enough. The change makes sense then.
        cyborgsnowflake 8y ago
        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.
parfe 8y ago
>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.html#unicorn-worker-killer https://docs.gitlab.com/ee/administration/operations/unicorn...
- obl 8y ago
  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 ?
  - skrebbel 8y ago
    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.
    - pjmlp 8y ago
      Not when you have GC graphical debuggers like Java,.NET and JavaScript do.
- qop 8y ago
  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.
chinhodado 8y ago
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 https://gitlab.com/gitlab-org/gitlab-ee/issues/1984) - configurable tab width (https://gitlab.com/gitlab-org/gitlab-ce/issues/2479 https://gitlab.com/gitlab-org/gitlab-ce/issues/2479) - consecutive git blame for current revision (https://gitlab.com/gitlab-org/gitlab-ce/issues/37135 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 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 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.
- hunter23 8y ago
  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
  - rstat1 8y ago
    They've already done the first 2. Though the chat app part was done by someone else.
  - Vinnl 8y ago
    > 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 https://i.imgur.com/vWOxECQ.png
Walkman 8y ago
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.
- some_account 8y ago
  I'm pretty sure this doesn't happen on all Ubuntu installs. Maybe you have some custom stuff?
  - Walkman 8y ago
    I don't think so. The problem was that unicorn was not listening on IPv4 by default, but it was before 11.0. Weird.
- jobvandervoort 8y ago
  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 https://gitlab.com/gitlab-org/omnibus-gitlab/issues
  - Walkman 8y ago
    Here we go: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3615 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3615
- zingmars 8y ago
  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.
  - Walkman 8y ago
    Thanks for the tip, but this was one of the first things I tried beside gitlab-ctl reconfigure && gitlab-ctl restart
realPubkey 8y ago
When will it be possible to revert commits in non-master branches in the UI?
- Vinnl 8y ago
  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.
  - realPubkey 8y ago
    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.
    - Vinnl 8y ago
      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?
- jobvandervoort 8y ago
  I just checked, user Vinnl is correct that you can already do this for every commit, and targeting every branch.
gorset 8y ago
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-patches.html#separate-your-changes 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.
- jobvandervoort 8y ago
  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 https://gitlab.com/gitlab-org/gitlab-ce/issues/48328
  - gorset 8y ago
    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.
whafro 8y ago
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)
- marcinkuzminski 8y ago
  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.
- jsty 8y ago
  > $1000 a month for every employee? Typo? Pricing page [1] lists it at $99/mo [1] https://about.gitlab.com/pricing/ https://about.gitlab.com/pricing/
  - whafro 8y ago
    Thanks, edited!
- jobvandervoort 8y ago
  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 https://gitlab.com/groups/gitlab-org/-/epics/237 [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/6600 https://gitlab.com/gitlab-org/gitlab-ee/issues/6600 [2]: https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#unlimited-guests-for-free-in-ultimate https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#un...
a_imho 8y ago
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/ https://about.gitlab.com/privacy/ [2]https://about.gitlab.com/terms/ https://about.gitlab.com/terms/ [3]https://docs.gitlab.com/ee/user/admin_area/settings/usage_statistics.html https://docs.gitlab.com/ee/user/admin_area/settings/usage_st... [4]https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/735 https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/735
- icebraining 8y ago
  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.
  - a_imho 8y ago
    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.
    - merb 8y ago
      > 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.
flavor8 8y ago
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 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.
- sytse 8y ago
  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_83445448 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.
pknopf 8y ago
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
- skinnymuch 8y ago
  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.
  - pknopf 8y ago
    I felt like this thread is way more negative than the others. Most of the time, it is all love.
gravypod 8y ago
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
- sytse 8y ago
  Can you link to the issue? We're working on multiple things that might help monorepos.
  - gravypod 8y ago
    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 https://gitlab.com/gitlab-org/gitlab-ce/issues/18157
    - sytse 8y ago
      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?
apazgo 8y ago
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...
- jeremy_ 8y ago
  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 https://gitlab.com/gitlab-org/gitlab-ee/issues/3427
  - apazgo 8y ago
    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) Then building a more advanced version for EE.
sigzero 8y ago
Still can't upload more than one file at a time using the web interface.
amelius 8y ago
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).
- louiz 8y ago
  What’s wrong with having the issues, project management stuff, CI, etc in one place, as long as you control that place?
  - dspillett 8y ago
    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.
- batuhanw 8y ago
  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?

229 points by markdog12 8y ago

throwaway20934 8y ago

> 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...

artursapek 8y ago
Master of Ceremony? Scrum Master? Master Chief? What are they on about?
- chinhodado 8y ago
  Not to mention the default main branch of a git repo is master
  - artursapek 8y ago
    git push origin unoffensive-term-for-dominant-entity
    - martenb 8y ago
      Try "main"
  - sytse 8y ago
    We won't change that until git does. Of course you can customize your default branch.
  - tomjakubowski 8y ago
    Unlike the 'master'/'maintainer' role, the main branch does not directly correspond to a person.
    - sieabahlpark 8y ago
      A master/slave DB isn't a person either and look where that ended up.
  - mappu 8y ago
    Hg sensibly calls the default branch `default`.
    - Qwertie 8y ago
      Git sensibly calls the master branch `master`.
    - BigJono 8y ago
      That's funny, because it's pretty common to set a 'dev' branch to default and reserve the master branch for production code.
  - berti 8y ago
    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.
  - NicoJuicy 8y ago
    Where is the slave
- sytse 8y ago
  GitLab is about removing the needless ceremony to getting your application deployed.
- diN0bot 8y ago
  slavery, jim crow. being called or calling someone else "master" feels deeply troubling to many people in the US, and likely around the world.
  - artursapek 8y ago
    All of you whiteys should go tell Q-Tip and Phife Dawg to stop calling themselves "MC", this is cracking me up
  - hyperbovine 8y ago
    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.
diN0bot 8y ago
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.
- oblio 8y ago
  He mustered all the courage he could, to post using a throwaway account :)
- colechristensen 8y ago
  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.
- BigJono 8y ago
  I find the highly negative labelling of people as "dismissive" to be offensive. I think you need to learn some respect and decency yourself.
sytse 8y ago
In databases master slave is replaced by primary secondary. I think being inclusive means removing obstacles you might not see yourself.
- deleted 8y ago
  [deleted]
- qop 8y ago
  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.
- colechristensen 8y ago
  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.
  - zapita 8y ago
    > 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.
freditup 8y ago
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.
- cheald 8y ago
  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.
- kochthesecond 8y ago
  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.
voxadam 8y ago
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/ http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut/
sbr464 8y ago
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.
cup-of-tea 8y ago
I miss the days when software was judged by what it did and how fast it did it and names were funny and clever.
DoreenMichele 8y ago
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.)
user5994461 8y ago
Master is probably the admin role with full privileges. No idea what a Maintainer is.
- lloeki 8y ago
  Unbeknownst to you, you nailed it, because the "full privileges" role is "Owner", not "Master". "Master" really is "Maintainer".
jobvandervoort 8y ago
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.
- Qwertie 8y ago
  IMO Master makes sense. The Master user is in full control, there is no one higher than the master.
  - sytse 8y ago
    In GitLab the owner can do more than the master/maintainer.
    - Qwertie 8y ago
      Ah fair enough. The change makes sense then.
      - cyborgsnowflake 8y ago
        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.

parfe 8y ago

>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.html#unicorn-worker-killer https://docs.gitlab.com/ee/administration/operations/unicorn...

obl 8y ago
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 ?
- skrebbel 8y ago
  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.
  - pjmlp 8y ago
    Not when you have GC graphical debuggers like Java,.NET and JavaScript do.
qop 8y ago
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.

chinhodado 8y ago

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 https://gitlab.com/gitlab-org/gitlab-ee/issues/1984) - configurable tab width (https://gitlab.com/gitlab-org/gitlab-ce/issues/2479 https://gitlab.com/gitlab-org/gitlab-ce/issues/2479) - consecutive git blame for current revision (https://gitlab.com/gitlab-org/gitlab-ce/issues/37135 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 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 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.

hunter23 8y ago
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
- rstat1 8y ago
  They've already done the first 2. Though the chat app part was done by someone else.
- Vinnl 8y ago
  > 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 https://i.imgur.com/vWOxECQ.png

Walkman 8y ago

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.

some_account 8y ago
I'm pretty sure this doesn't happen on all Ubuntu installs. Maybe you have some custom stuff?
- Walkman 8y ago
  I don't think so. The problem was that unicorn was not listening on IPv4 by default, but it was before 11.0. Weird.
jobvandervoort 8y ago
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 https://gitlab.com/gitlab-org/omnibus-gitlab/issues
- Walkman 8y ago
  Here we go: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3615 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3615
zingmars 8y ago
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.
- Walkman 8y ago
  Thanks for the tip, but this was one of the first things I tried beside gitlab-ctl reconfigure && gitlab-ctl restart

realPubkey 8y ago

When will it be possible to revert commits in non-master branches in the UI?

Vinnl 8y ago
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.
- realPubkey 8y ago
  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.
  - Vinnl 8y ago
    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?
jobvandervoort 8y ago
I just checked, user Vinnl is correct that you can already do this for every commit, and targeting every branch.

gorset 8y ago

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-patches.html#separate-your-changes 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.

jobvandervoort 8y ago
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 https://gitlab.com/gitlab-org/gitlab-ce/issues/48328
- gorset 8y ago
  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.

whafro 8y ago

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)

marcinkuzminski 8y ago
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.
jsty 8y ago
> $1000 a month for every employee? Typo? Pricing page [1] lists it at $99/mo [1] https://about.gitlab.com/pricing/ https://about.gitlab.com/pricing/
- whafro 8y ago
  Thanks, edited!
jobvandervoort 8y ago
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 https://gitlab.com/groups/gitlab-org/-/epics/237 [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/6600 https://gitlab.com/gitlab-org/gitlab-ee/issues/6600 [2]: https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#unlimited-guests-for-free-in-ultimate https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#un...

a_imho 8y ago

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/ https://about.gitlab.com/privacy/ [2]https://about.gitlab.com/terms/ https://about.gitlab.com/terms/ [3]https://docs.gitlab.com/ee/user/admin_area/settings/usage_statistics.html https://docs.gitlab.com/ee/user/admin_area/settings/usage_st... [4]https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/735 https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/735

icebraining 8y ago
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.
- a_imho 8y ago
  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.
  - merb 8y ago
    > 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.

flavor8 8y ago

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 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.

sytse 8y ago
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_83445448 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.

pknopf 8y ago

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

skinnymuch 8y ago
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.
- pknopf 8y ago
  I felt like this thread is way more negative than the others. Most of the time, it is all love.

gravypod 8y ago

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

sytse 8y ago
Can you link to the issue? We're working on multiple things that might help monorepos.
- gravypod 8y ago
  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 https://gitlab.com/gitlab-org/gitlab-ce/issues/18157
  - sytse 8y ago
    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?

apazgo 8y ago

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...

jeremy_ 8y ago
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 https://gitlab.com/gitlab-org/gitlab-ee/issues/3427
- apazgo 8y ago
  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) Then building a more advanced version for EE.

sigzero 8y ago

Still can't upload more than one file at a time using the web interface.

amelius 8y ago

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).

louiz 8y ago
What’s wrong with having the issues, project management stuff, CI, etc in one place, as long as you control that place?
- dspillett 8y ago
  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.
batuhanw 8y ago
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?