I'm fine with getting rid of the template, I think it's much less relevant now that home is no longer a single dashboard.

I think we could even default it to "fancy mode" without a setting, at least to start with. I'm not sure anyone will want to access the plain text mode with enough frequency that we need it to be sticky.

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.

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.

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

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.

Mine's fine here, too:

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

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.

No, it would not.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable. Thanks for the report!

I think this commit in the Git upstream is probably the culprit (January 2016):

Does it work without the --?

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

The setsid() appears to have resolved the issue, in the sense that daemons are now starting cleanly every time without receiving any inexplicable signals.

The MySQL stuff seems to be in the old daemons (them trying to do logging while MySQL restarts), not the new daemons, and not the cause of the issue.

We have no plans to move this forward or enable it in the Phacility cluster in the near future.

We can also do other stuff like "never archive an instance with 2+ users", "after an instance emails us to unsuspend, have a flag to mark it as exempt from cleanup in the future", "don't destroy data for 365 days, instead of 90, if an instance had hosted repositories", or other sorts of things like that, but I suspect measures like that will be largely unnecessary for years to come and that "no one loaded a page for 45 days" is already a nearly perfect signal for "no one cares about this instance".

Continuing from above, I queried a subset of instances for session counts to help us understand usage patterns for free instances (see T12217):

Picking a random shard, 80% of the active instances have zero sessions in the last 30 days -- so no user has loaded a single page in at least a month. Most (maybe all?) of these have only one account. These include (anonymized) free instances like "alsdknfasf", "test2", "test2017", "testinstance9", "testforme", "mytest", "myinstance", "bbbbbbb", "ddeemmoo". Of the 20% of active instances which do have activity in the last 30 days, many are recently-launched free instances with only one user session, and I'd guess many of those users are never coming back and these instances will join the boneyard shortly.

My thinking is that v1 would work like this:

I'm going to put D17497 + D17498 into this release even though they don't directly tackle the issue here and I think they're slightly risky changes (mostly because git ls-remote may have odd behaviors in some cases, and we don't currently use it in other workflows). But they may help with T12296 and general cluster load issues, and the followup changes will generally be more complicated to reason about (more locking/concurrency stuff), so I think getting these in earlier spreads risk out somewhat even though they're something to watch out for in this release.

Yep, that's what I'm thinking too.

Yeah, and the sane version (add to dashboard, not to tab panel) is probably not too awful and won't really make fixing T8033 any harder.

Getting rid of all "Select Existing Panel" flows also makes simplifying the "Run a query -> turn it into a panel -> put it on a dashboard" workflow a bit more of a mess, especially if we want to try to do "run a query -> turn it into a panel -> add it to a tab panel". But I think in the long term making the T8033 problem impossible and then trying to do our best with the "query -> panel -> dashboard" flow is the best bet.

As long as you're selecting existing panels in any interface, we're stuck with the problem in T8033. I think we can only fix that elegantly by removing all interfaces where you select panels, and replacing them with interfaces where you create panels.

The change I imagined there was:

If we make the permission changes discussed elsewhere (T8033, I think?), this might just become something like a containerPHID which points at a Dashboard for panels created from dashboards, another Panel for panels embedded in panels, and null for standalone panels.

We don't plan to support this. Large installs often have hundreds or thousands of open revisions, so "build all open revisions" would trigger hundreds or thousands of builds for every push.

Thanks! This code has been churning recently (T12298 / T12217) and I likely broke this in D17389. I think I observed this behavior, but this report should save me a great deal of time hunting the bug down.

You can already use third-party externals that use namespaces, and we already bundle some (Twilio, Balanced until it was removed in D12074).

(You could also pipe the list into bin/remove destroy --force, equivalently.)

You can re-run the migration explicitly with:

Thanks. D17507 should fix this, and will un-stick any tasks stuck in queue.

Thanks! D17506 isn't the most elegant possible patch, but should fix this. Let us know if you're still seeing issues after that lands.

It is likely that the vulnerable code predates significant portions of the Files and permissions systems, and was just overlooked as these other systems upgraded and gained more powerful policy and permissions capabilities.

The fix is now available on master (rP7626ec0c) and stable (rP6f879559). I've upgraded this install without incident. Per above, note that upgrading destroys evidence, so you should plan any audit or response actions you want to take before upgrading.

T9789 has stabilized (the majority of major transaction types now run through ModularTransactions) although it didn't end up providing much clarity here. This is no longer blocked on anything, I just need to develop a specific technical plan to resolve the "adjust" vs "expand" sequence inside transaction application so the "expand" code has access to the old text by the time it runs.