I accidentally stumbled across the root cause for this and I think the fix is a one-liner, so it should work better after D15391.

Ok thanks. I found it very confusing.

Well, sort of. Projects don't get set correctly with explicit column.

column should be a PHID.

Yeah, this was mostly-intentional while resolving T9527 / T7661.

T8153 possibly also related (detect someone broke the resource and destroy it so it gets recreated).

We don't have a secret internal Phabricator full of juicy status updates: if we make progress, we'll update this task. See Planning for details.

We already have this.

See Contributing Feature Requests.

Yeah, they're hard to separate -- available rules depend on configuration, installed/uninstalled applications, extensions, and version, and individual rule behaviors may depend on things like the presence of dependencies on the system (for example, whether cowsay works, and which cows are available).

Yeah, the local help pages aren't generated by Diviner -- they're generally generated from the configured code at runtime.

It is very unusual for documentation to exist locally, as generating it currently requires building xhpast and doing setup on Diviner.

You may be able to call HTTPSFuture::setBlindlyTrustDomains(...) from preamble.php as a possible workaround, although you'll have to load some libraries first and this may interfere with error handling. Alternatively, you might be able to write an event listener which only calls this method as a side effect and does not listen for events (event listeners are allowed to run registration code early in the startup process).

Can you walk me through why can't you add the internal certificate to Phabricator's trusted CA chain?

I think that would be reasonable.

Why not change Phobject::__isset and Phobject::__unset to throw an exception in the same way that Phobject::__get and Phobject::__set do?

Thanks! Should be fixed by D15368.

• Provide some way to treat "too much output" as a categorical build failure, similar to how you might treat "excessive runtime" as a build failure.

Sounds like this has been resolved.

See script in T10350.

which svn client do you use ?

This should be fixed in HEAD. Thanks for the report!

Current plan here is:

@tycho.tatitscheff See T8656 or Planning.

Unfortunately, this bug is reproducible on my installation by simply visiting the Diffusion URL, there are no other steps.

See also:

This has been open for several months without forward progress.

It seems like this isn't reproducible in other environments. Feel free to file a new report if you are able to uncover more information in the future.

Note that those are the actual names of the tabs (not, say, some weird internal hash, as I thought at first glance), the list just isn't getting rendered properly:

This is real dumb, but I think it only creates a moderate inconvenience so I probably won't try to dig into it until we do the next iteration on dashboards.

That fix isn't retroactive, but should stop the problem in the future once it deploys. Thanks for the report!