In T12296#216132, @epriestley wrote:

While the git ls-remote change isn't really motivated as a performance improvement, it does seem to have reduced CPU usage a measurable amount (deployed on the morning of 3/18), maybe 15%:

While the git ls-remote change isn't really motivated as a performance improvement, it does seem to have reduced CPU usage a measurable amount (deployed on the morning of 3/18), maybe 15%:

The cause of this was mundane: the daemon queue has a large repository import in it, so the repository search update got stuck behind the import tasks. Manually forcing an index update with bin/search index Rx fixed the index.

We have no additional design plans around hovercards.

I don't really consider this behavior a bug, because this (users registering into zero spaces) isn't really a supported workflow. The menu rendering is less ambiguously a bug, but I'd likely fix it by just hiding the menu in this state, and that won't address your issue. And it doesn't cause any problems unless you get into this questionable state in the first place, so cleaning it up is difficult to prioritize.

Oh, I see...so, no luck there...but this would be a great option if it worked the way I initially understood.

Tezt comment

"Can Create (Non-Bot) Users" is a fake permission for Phacility SAAS disguised as a real permission. You must always have that permission and be an administrator to create users: that is, it can only be used to reduce the set of administrators who have permission to create users. In the Phacility SAAS cluster, we set this permission to "No One".

In the short term, if you want to email me at support@ with the details, I'll fix these manually. We've rarely seen this request and the cost to build this self-serve, even if it didn't have product issues, is greater than the cost to manually fix all known cases for now. I'll build some kind of self-serve solution at the point when I get tired of doing them manually.

Why should verifying email address depend on any space view policy?

IMHO, that's more likely what you want in most use cases anyway. I can imagine
quite a bit of confusion arising if you modify a query for a dashboard and it
unexpectedly modifies what shows up elsewhere.

We could conceivably do something like "edit this query" link from the panel, and have that take you to /application/query/wzyx/?panelPHID=asdf, and that generates a "save this query back to panel X" option in the UI.

Hmmm, not sure there is any path here, I seem to recall we can't allow editing of saved search queries without generating a new key? And if we generate a new key, we'd have to find all the Dashboards it's attached to?

This sounds like the expected result to me. Even if they did get verified, they would immediately hit the same "No Access" dialog again.

well that was a waste. lolz. 🐈

I can't reproduce this with the steps provided. Here's what I tested:

You are my hero! :)

Also, really great bug report :)

Do you maybe have SELinux or AppArmor running?

Mine's fine here, too:

Only 5? I expected more.

Fair point, there was a bit of overlap, and the end result of a revision is super important (the commit).

Yeah we had both "commits" and "revisions", which had a bit of overlap. My main concern was if you were using this information to learn about a person, actual commits should hold more weight over temporal information like revisions.

Interesting, that decision makes sense to me.

(Commit-date ordering would also mean that forward-dated commits would be stuck to the top forever.)

That is, we order things by discovery date (when we learned about the existence of the commit), which is tamper-proof, rather than author date or committer date, which are freely mutable by the client.

If you just updated after more than a year, you are probably seeing imports from the change in T6878. Once those finish, things will settle down and "commits" will begin reflecting what you expect.

I believe there are plans to update it more than once a year at least

I'll take a look at the commits bug here shortly. Do you expect your install to keep more up to date?

Sure, apologies for the lack of clarity.

Or more specifically, I don't intend to add this back without spending more time thinking about the problem it solves. There are other possible solutions (including allowing installations to customize a user's sidebar) but in the context of doing a code review, I can't think of any benefit here. It's helpful for us to understand the entire problem you're looking to solve. If knowing a user's current revisions is important in the context of performing another code review, we'd like to know what that information is and why. What information do you get from it, and what decisions do you make differently because of it.

What is the root problem you are looking to solve? See Contributing Feature Requests and Describing Root Problems.

@epriestley, I tested out the scenario with the change applied.

I apologize, just this error is so floating that I still can not understand at what level it is. Now I come home, I load the picture - and it loads well enough.

Downgrading accepts and rejects (changing "Accepted" into "Accepted Older") uses raw edge transactions.

The Herald case and the next case (newAutoReviewTransaction()) both have some code duplication around prefiltering reviewers before building transactions for them.

Instead of using open registration, can you invite users instead and immediately add them to spaces so this doesn't happen? Why are you allowing open registration if all registration must be coordinated with an administrator anyway?

This is vaguely involved.

It sounds like this is resolved.

We don't plan to take any other upstream actions here, but let us know if anyone has further questions.

Please provide complete reproduction steps the upstream can follow as well as your installs version information. This information is required before we accept any bug report. See Contributing Bug Reports for more information. If you'd like a clean environment to test in, please use a test instance at Phacility.