You're welcome to use whatever database tools come with whatever database you're using to check for corruption, but not likely the issue.

Is there any script which check if the database is not corrupted?

Strange. In one project I have 3 milestones and I can tag only one. In other project I have 2, but I can't tag any of them.

I can't reproduce this.

Have you seen these warnings when creating your feature request?

Also I tried to give you a thorny plant as an offering/warning/omen but it turned out to be a drink. Maybe both were in order.

Clue!

@cspeckmim it's gonna get crazy in here.

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.

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