Or: if you aren't comfortable adding labels to a menu, you probably don't have an organizational role that requires you to pin 5 dashboards into subgroups on your homepage, and you can figure out how to customize it later when you need the increased power. Novice users can always use browser bookmarks or normal navigation, or administrators can add links to the global nav if there are actions that some users are consistently having difficulty with.

We can have an "add this page to the homepage menu" that just adds a link at the bottom of your custom stuff, and/or "Customize Menu" can take you to a modal choice between "add a link" and "do powerful things". But I think most users can handle it -- I don't recall too many issues with project profile menus, and when we removed them we got a fair amount of pushback so it sounds like the full-power version is getting use today.

Yeah. Default looks like this:

I think that's reasonable, but I'm not sure we even need to separate out dashboards -- if we do, it prevents me from putting them into functional sections I create with labels (like "Engineering").

(Or, if you're ambitious, you add 20 different links in 5 categories or whatever, and effectively replace the global menu with your own custom thing full of stuff.)

I think user links should go first, so they push all the global stuff down, out of the way. You add links for the 3-4 most important things, they show up at the top, and then presumably you aren't too concerned that admins occasionally shuffle the other stuff around since it's out of your way.

I'm not sure trying to auto-categorize is desirable because it means that stuff like create forms, wiki pages, etc., won't end up in the most logical place. It prevents me from creating an "Engineering" category for a company, or a "Getting Started" category for onboarding users on an open source install.

Seems to be working now. ¯\_(ツ)_/¯

For future reference, here's the sequence of problems I hit:

Your config looks very little like the config we recommend. Why are you using try_files instead of rewrite?

Can you show me:

GREAT NEWS! Times work again for me, personally.

This is pure scope creep, but I've always found Countdown anticlimactic when it reaches 0. I could imagine having this feature:

The intended target of the link is Cluster: Databases.

I can rename them, maybe MenuItem instead of Panel? I think when I wrote the stuff we had some more panel-like items in mind (like M1450) but haven't ended up building many of them, at least so far (cat facts and progress bar are the only non-item-like-ones, I think). Even if we do build richer stuff later I think MenuItem is reasonably clear.

One thought about binding them to dashboards is that users won't naturally be able to edit the menu anymore, to personalize it. But maybe we can put some kind of override mechanism on top of it.

I hope so!

That's expected if innodb_ft_max_token_size is not defined; specifically if this returns an error:

What is innodb_ft_min_token_size set to? The default is 3.

See Planning for discussion of updates and timelines.

What are the barriers you face to hosting on Phabricator instead of on GitHub?

The provider is now being removed from Phabricator, so 2016 Week 49 is the last release to include it.

Generally, I am leaning toward splitting the "Commit" rule into two rules, "Commit" and "Ref Update".

We have some spooky magic around "autoclose" which might make the behavior for "Is on autoclose branch" different than "Is on <specific, named branch>". That said, I'm not sure if it's actually materially different, and these likely end up being more-or-less the same thing when we actually fix them.

T11953 isn't exactly the same as this, although they're similar.

Oh, maybe this isn't quite the same as T6522. Pushing another commit to the branch probably fires the rule?

This has been running cleanly in production for roughly two weeks, and appears stable. secure001 stopped writing Files data at F1943597 and we're now at F2078289 on secure003. We saw a couple of minor setup issues (mostly: exception messages not being tailored enough) but no fundamental issues.

We also made some changes to this recently (D16936, D16983) and it could conceivably be a version issue, but neither of those changes replaced a static cache with a RequestCache or similar, and D16936 is correctly using the RequestCache (which is cleared when the taskmaster de-queues a new task).

I can't reproduce this in the Phacility cluster, either. Here's what I did:

I'm not immediately able to reproduce this. Here's what I did:

From elsewhere:

I believe this is now resolved at HEAD of master. Let us know if you're still seeing issues after updating.

I believe HEAD of master can now accept IPv6 requests, with the caveat that most of my testing has been at least somewhat synthetic and I haven't set up a legitimate, dedicated, IPv6-only host anywhere to be certain it works. That said, I'm reasonably confident that my synthetic testing was fairly thorough, since not very much code really cares about the remote address and I was able to make legitimate requests to ::1 over HTTP and SSH, and from synthetic IPv6 remote addresses. If you run into issues with sending IPv6 requests to Phabricator, let us know.

I'm planning to support this in the arc experimental branch, although initial support won't be optimized. We can look at ControlPath and/or adding batching to the protocol layer to improve performance once it works.

I'm going to merge this into T550 since it sounds like that's the immediate way forward, at least.

The section in T11922 only applies to the storage engine portion of that change, not to reindexing in general, and dropping the index is likely to hurt things overall if we need to do this more in the future (no performance improvement but totally nukes the search index until the reindex occurs).

Cool. For context, stuff I expect to do upstream, sooner or later, since I consider it unambiguously good (just not necessarily high priority):

Can you outline the attack scenario or scenarios you're concerned about?

Good enough for me.

(I don't consider is a bug: we're consistent about showing modified date across all applications which show a date, as far as I can tell, and omitting a label is a product decision.)