phikai

Hey - I'm the PM for our Code Review group. Sorry to see you're running in to that issue, it's been a real challenge for us. If you're running in to it pretty often, it'd be great if you could provide some details on what steps you're taking (maybe even record a video) to help us figure out what's going on. For lots of bugs, the hardest thing for us to do is reproduce them... so if you've got a reliable way to do that, it really helps us prioritize things to fix.

> Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh?

I don't think I've seen that reported before and we have been working through some interesting to reproduce issues in recent milestones.

Would you mind opening an issue for this? Feel free to tag me (same name).

I'm so excited for this too! I'm really excited to continue bringing GitLab workflows closer to where developers are doing their work and hope this is going to be a really meaningful step in that direction.

I'm also interested to see what kind of impact it has on large MRs, but do know it's not the answer for what happens in GitLab.

One more thought on all of this - we're currently doing some research on problems users face in the merge request. Feel free to take our survey: https://gitlab.fra1.qualtrics.com/jfe/form/SV_9HQQil77CjHJIC...

Bonus... you can enter for a chance to win a $75 Amazon gift card.

Hi! I'm not sure if you've seen this, but in GitLab 13.0 we released commit based navigation for merge requests. You can read more about this in our docs, but we'd love any feedback you have on the feature.

Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/revie...

Hi! Thanks for the feedback on diffs - it's something we're always thinking about and working on in the group.

One of the things we're currently working on is putting monitoring in pace for all the of the diff limits - https://gitlab.com/gitlab-org/gitlab/-/issues/31063. The goal here is that we can further fine tune some of the limits in place to continue to help with larger merge requests.

The group also spent some time investigating ways to improve the blocking time for large merge requests and you can see some of the discussion around that here: https://gitlab.com/gitlab-org/gitlab/-/issues/295237.

The last issue I'll drop here is https://gitlab.com/gitlab-org/gitlab/-/issues/241841.

You can also see all of the other issues related to performance that the Code Review group has been working on in GitLab here: https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8...

Thanks again for the feedback - and know that this is something we are looking in to.

Hi! I'm the PM for Code Review at GitLab - thanks for all the feedback. The team really knocked it out of the park in 13.9 so it's great to see that being recognized.

> 1. Marking whether a comment requests changes or not. This is of course straight out of GitHub, but I think their flow better matches what I found to be happening a in a lot of changes. I see such states for a Code review of a MR: Changes approved, Reviewer requests changes, reviewer leaves feedback (like "nice implementation", "good refactor", "minor: maybe you can refactor this?"). The last one is the most blurry in the GitLab approach since the way we can solve it is by starting a comment thread that is not resolved and approving a MR at the same time but it feels clunky. Maybe they can take a page out of GitHub's book.

This is something we've been thinking about a lot and want to address. Right now our comments are pretty murky in that it's not clear what might be required. We'd like to add some kind of support here to make that clearer and you can see some issues in https://gitlab.com/groups/gitlab-org/-/epics/4349

We've also been thinking about this in the handoff part of the reviewer workflows (https://gitlab.com/groups/gitlab-org/-/epics/5074), as a way to signal what the expectation from the reviewer is once they've finished the review.

Stay tuned!

Hi! I'm the PM at GitLab who works on Snippets, so thanks for providing this feedback. We do have Recaptcha support which can be configured - are you seeing these kinds of issues with that enabled/configured?

One item that is on the roadmap that is coming and may be of interest is `Optional Admin Approval for local user sign up` - https://gitlab.com/groups/gitlab-org/-/epics/4491.

I'm not in the group working on that, but it does appear to be coming soon and would limit the ability of newly created accounts from doing anything until they're approved.

As a GitLab team membmer, this is really awesome to see! A GitLab CLI is something I'd love to have officially at GitLab. Feel free to contribute to the discussion and help up vote the idea here https://gitlab.com/groups/gitlab-org/-/epics/3324

> But anyway the double brackets is not a Gollum feature. It's a wiki thing, going back to wikipedia.

That's fair, the point was that it's syntax specific to the wiki system vs. the rest of our markdown filters.

> Since you're here I think this issue is also misprioritized: https://gitlab.com/gitlab-org/gitlab-ce/issues/66898 You should reconsider as a lot of integrations rely on webhooks and broken images make the whole thing impossible.

I'll take a look at this - it popped on to my radar recently but I need to dig in further to understand the use case and functionality here. Thanks for bringing it up.

> Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search).

Hi! I'm the current PM for our search and as Sid mentioned we've steadily been working to improve that. It's been getting a lot better, but most of the improvements are heavily reliant on also having Elasticsearch enabled. Without that, there's really no way for us to provide a optimal search experience for the amount of data and content there.

If you have any specific search feedback, please feel free to open an issue or reach out to me @phikai on GitLab.

> A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration.

Hi! I'm the current PM for our wiki's and I agree that the experience isn't up to par at the moment. As Sid mentioned, historically wiki's were not a priority as many users weren't coming to GitLab for those features. We're starting to see shifts in that thinking as we've penetrated deeper in to some markets so we're working to adjust accordingly.

> It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog".

That issue is interesting because it's a link mechanism that relies on the underlying wiki project that we use. (i.e. that's no common markdown syntax). Discoverability of things like that is limited to some power users who know that we're using Gollum underneath and know of some of the supported syntax. What we've seen is that most users don't use that functionality and instead just use absolute links in markdown. This likely explains why the upvotes are so low on the bug report as well.

For comparison, we've seen more demand to support linking to projects: https://gitlab.com/gitlab-org/gitlab-ce/issues/20726, than within the wiki itself.

As an FYI, I've also asked a couple of our engineers to take a look at that specific issue to see if it's something that can be relatively easy to fix. No guarantees on anything here, but we'll try to get a bit more relevant engineering information to assist in understanding scope.

> If you really do feel this way about the wiki then it should be clearly marked in your marketing.

That's a lot of what our maturity pages are trying to do. We're being honest with ourselves and with our users about where we think the functionality of certain features are. In fact, when I started we had the Wiki listed at a `Complete` maturity which I reduced to viable: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

If you take a look at the wiki strategy (https://about.gitlab.com/direction/create/wiki/) our next focus is going to be on making editing easier and improving navigation. We think these things will start to move the conversation forward for users and we'll see more adoption.

Even more, if you think we're not moving in the right direction with the Wiki's please be vocal on the issue tracker, or open an issue for the Wiki Strategy or even a merge request to change something. We're happy to have the feedback, and don't hesitate to tag me on wiki issues I'm @phikai on GitLab as well.

THIS... elebenty billion %. The breaking changes of PHP upgrades make the hosting life a nightmare. It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people.

Outward appearance, vanity, they actually have the free cash, ignorance. There's a bunch of reasons people buy expensive cars... most of which don't make sense other than that's what they choose to spend their money on vs. whatever you've chosen to spend your money on.

It's also an entirely incomplete picture on their financial situation. Maybe they have a paid for living situation so this is their only liability, maybe they don't have any money in their savings account, maybe they don't have a retirement account.

And with Tesla it's probably even more complicated because there are some "feel good" motives to buying an electric car that may outweigh any sane financial decision.

Shout out to a fellow San Antonio local!

That's the answer... shift the emissions burden to power companies and battery disposal companies! But I'll feel good driving my "zero environmental impact" electric car around!

I have a 10+ Year old AMD based system with a small SSD, and 4GB of RAM running the whole thing with plenty of capacity to spare.

OP Here... This is my little project to setup my media server in the house. It's been working really well for me and I've been receiving some great feedback on it. I'd love to get any comments/questions or help with the project that anyone has to offer.

99% Invisible did a great story on this called Devil's Rope [0]. It's pretty amazing what people were able to accomplish.

[0] - https://99percentinvisible.org/episode/devils-rope/

I noticed it based on Pi-Hole [0] and seeing the excessive DNS Requests to those URLs... started googling and found this post which I thought summed it all up nicely. Looking at the author's post, it also appears they noticed it due to Pi-Hole as well.

EDIT: It was a different post that someone had seen this via Pi-Hole. Not sure how the original author discovered it.

[0] https://pi-hole.net/

Where I find this really excels is the excellent query mechanism here: http://linux.die.net/man/1/grep

A lot of that has to do with features and quality of the service. If you have advanced DNS needs (failover, traffic directing, etc) you may need to use a third party. If you have very basic needs sometimes the host can provide those easily for you. Additional conversation: http://stackoverflow.com/questions/8605200/settings-dns-reco...

A lot of that has to do with costs and service levels provided by your DNS provider. There's a couple of good points at Server Fault: http://serverfault.com/questions/388289/what-are-the-benefit...

We'll be deep diving on specific record types and their uses next week.