Just as input: Versioning/Updates would be really useful if we update our ToS for our end-users and we need them to be required to review and re-sign on change

May be easier to rename Dashboard Panels to Panes or Windows or MacOS

Actually this seems like a lot of work

Do you mind if I rename "ProfilePanelEngine" to "MenuEngine" or something else less vague?

I think fixing the entire dashboards experience should help though. I don't plan to just shoehorn this in.

Oh

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.

oh @epriestley is at the dentist.

CatFactsEngine

Though I feel like we should rename PanelEngine to MenuEngine

I hope so!

I think that's right

didn't know I could drag and drop your events

whoops

Applied D17001 and confirmed fix. Thank you.

> select @@innodb_ft_max_token_size;
ERROR 1193 (HY000): Unknown system variable 'innodb_ft_max_token_size'

What you describe sounds familiar. I can find NTP and EoL. I can find NIS* but not NIS, DNS* but not DNS.

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

FYI this is where things are at after storage upgrade on Week 49 stable using MariaDB 5.5. Is this what you would expect?

Note that full text indexing for InnoDB and hence innodb_ft_min_token_size were only introduced in MariaDB 10.0.5. RHEL/CentOS 7 ships with MariaDB 5.5 :( Ref: https://mariadb.com/kb/en/mariadb/fulltext-index-overview/

Found it and edited my comment, it was indeed innodb_ft_min_token_size at fault.

What is innodb_ft_min_token_size set to? The default is 3.

After this update I couldn't find three letter words any more. I needed to add this change to the MySQL config:

See Planning for discussion of updates and timelines.

It is more than one years, so any update for this feature request?

Purely organizational. I don't believe there's anything technically that Phabricator can't do, but we're just trying it out and don't want to move everything over before we're ready to commit.

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.

Sounds like this can safely be closed as PEBKAC

FWIW, in this particular case our repository is hosted on GitHub, so lovely automagic in Phabricator wouldn't solve my specific case.

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.

I think it is the same as T6522?

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:

Your logic there w/ dumping the prefs is definitely convincing. Perhaps I hallucinated this and it was actually that I did something in a different order, e.g. I disabled "A commit is created", then restarted the daemons, then disabled "A commit has auditors added" and misattributed causality (where the real issue was that disabling "A commit is created" is not sufficient to stop receiving emails when a commit is created that you're an auditor on).

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

Why does the mail say you received it, see /mail/

From elsewhere:

We have updated to Git 2.11 and updated to master pull/push works for us. Thank you as always. :)

In T3179#198521, @michelkaeser wrote:

In T3179#142498, @lfarkas wrote:

Trac wiki import to Phabricator's Phriction.

Based on svemir's anser in https://secure.phabricator.com/Q12 a not to nice not perfect but more then nothing:

https://github.com/lfarkas/phabricator/blob/master/scripts/util/trac_wiki_import.php

@lfarkas the Github link results in a 404. Do you still have a copy of this script? I am in need of a Trac Wiki importer and yours seems the only one available. Or does anyone else have a working script?

Thanks in advance.

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

Hi folks,

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.