Yes, but I is also reported by jsHint: https://github.com/jshint/jshint/blob/2.1.4/src/shared/messages.js#L195

jshint linter only allow W and E prefixes - https://secure.phabricator.com/diffusion/ARC/browse/master/src/lint/linter/ArcanistJSHintLinter.php;2234c8cacc21ce61c9c10e8e5918b6a63cc38fc8$145

jshint version is the latest: jshint v2.9.2. I'll add more infos to this ticket soon...

I disabled the APC extension but still had the same issue. I'll try deploying on CentOS 7 when I have some time.

Specifically, what version of JSHint are you using would be most helpful.

Software versions and steps to reproduce are required information for us on bug reports. Do you mind filling this out please? See Contributing Bug Reports.

Try disabling php-apcu and other performance related extensions. Some of them (like APC) are known to cause segfaults or other issues, so unless you actually need to have them installed, I'd suggest disabling them and see if the issue still occurs.

This sounds like an issue with either git clone or the SSH client installed on the build machine itself, and not Phabricator. I don't believe upstream offers support for configuring build agents (they don't offer support for envionment issues on machines that host Phabricator, let alone environment issues on machines that Phabricator uses for builds).

Ugh.

Great, thanks! (And with clarity I meant instant visual clarity for people who haven't been involved in designing them)

I went with checkered for now.

@chad Do I understand you correctly, there would be just outright white background for transparent areas with your patch?
The checker background gives clarity as we have to make sure that many of our interface elements shown in Pholio mocks are working on dark and white backgrounds.

I'm more inclined to remove the checkerboard outright from view. The main concern here is if it's confusing on the edit page, then it's also confusing on the thumb and embed views. The only place we use checkerboard is on the full view page itself.

Not sure if this was just a test or not, but it's doesn't look like a bug report. See Contributing Bug Reports for help writing good bug reports.

This is an invalid task here, but in any case https://phabricator.wikimedia.org/ does work, also for anonymous users.

What does arc which say before you run the final arc diff?

Same here. I've created customfield "Requirement" to identify external Requirement ID. Searching using Contains Words is inadequate cause it search all fields containing similar string.

Can you list out a complete set of reproducible steps to follow? Is this a Dashboard you're building and installing on other people homepages, for example?

Third-party applications which assume dateModified means "last 'meaningful' update" are written incorrectly. It does not mean that, it is not documented to mean that anywhere, and it is clear from the code that it doesn't have this behavior. It is unreasonable to assume that the only possible purpose of this field is metric extraction. This field is a low-level field which serves a different set of goals. It explicitly does not serve metric extraction goals.

In T10989#176079, @Danny_B wrote:

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)

In T10989#176072, @epriestley wrote:

These are third-party extensions, not other upstream applications, right?

Yes.

Why do you consider this to be a bug in Phabricator rather than in those extensions? Does the documentation say "this field is updated only when a 'meaningful' update is made to an object, and you can and should rely on it to have this behavior when extracting data from Phabricator" somewhere?

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)
Inability to do such stats due to unreasonable dataset below makes Phabricator (otherwise good application) useless for teams which are trying to improve (read: shorten in this particular case) the task life-cycle - and that's pretty much every team since noone wants to have long time untouched tasks without any action taken... ;-)

In fact it breaks various monitoring/statistics depending on last update

But moving on the workboard is no update at all... It is null action.

https://secure.phabricator.com/book/phabricator/article/diffusion_uris/#observe-a-repository

"Last Update" is low level, and includes some actions which do not appear in the task history. This is expected.

D14566 might fix this? See also T9640.

PHP7 is currently unsupported, I would start there and move to 5.6 or whatever you prefer.

Yes, I tried it on my work computer (same versions and configuration), and then on my home computer.

Can you reproduce this on another machine?

I have been unable to repro on a clean install. Its probably appropriate to close the bug. I apologize for being unclear.

D15942 restores the project tag transaction to the first mail about an object:

I guess this originally had several different parts. My thinking on the parts are:

or that

Better to do the header tags in the body text thing?

I think we're mostly unsure what we want to do here.

Is this task open to be Prioritized? Wikimedia is discussing the possibility to fund it at https://phabricator.wikimedia.org/T135327

These tattered edges are an expected consquence of destroying objects, and the Phabricator upstream will not help you fix them. We strongly recomend disabling or archiving objects instead.

Ok. I assume you know about such issue so you prefer not to report it in future?

Thanks for the quick fix.
I realise now I was always trying to change the access policies....

Yep, works now. Thanks

Thanks, try HEAD?

D15934? looks like it introduced "suffixes" for reviewers.

I'm not sure if this change is correct, but it seems to fix the issue for me: https://secure.phabricator.com/differential/diff/38381/

arc diff is not expected to upload coverage information without additional configuration.

I think the output format from differential.parsecommitmessage has changed:

Whatever's generating your coverage information (A unit-test engine) needs to provide file names relative to the root of the repository; The snippet you have is showing the filenames are absolute.

Oh, this is probably the correct error log:

Server-side, I have the following commits deployed:

Updated version information:

You're also two months out of date, see Contributing Bug Reports.

Please include reproduction steps when filing a bug report. See Providing Reproduction Steps for help.

When you deleted the user, did you see this prompt?

Ah, thanks for following up. That's interesting and a little perplexing, although just fixing this stuff via T10967 is probably still the best way forward. I'll keep an eye out for similar reports, though. That does tend to make me think it might be a real race.