Is this rule a lint-like rule, in the vein of T7617? See also T10523 for discussion of lint-like rules.

Yeah, I think the existing "Edit" page should really be more like the "Manage" page in Projects that anyone who can see the repository can see.

If anyone else set up a cron job or similar to keep a staging area with a fresh master, you should be able to throw it away after users upgrade past T10509. That task has some details.

Aha! That makes sense, thanks for digging into it!

If the motivation is primarily social, you might be able to use a social permission:

Part of the pathway forward here may also be to reduce the prominence of subprojects in typeaheads/lists, or reduce it conditionally or something.

This is currently intended, although I think it's not out of the question that we might relax it or otherwise take another look at it.

Awesome, thanks!

This is probably at least somewhat reasonable, and we do something vaguely similar in the Maniphest list view.

I'm a little worried that doesn't make for a great out of the box or support experience since almost anything interesting will require extensions, but that is basically the case anyway today.

Is it reasonable for this value to be part of the job name?

Maybe this is a better question: if someone else files a similar task saying that the repository projects or date created or full list of tags or default branch would help them glue to Jenkins/Travis/Hudson, when should I say "yes" or "no"?

I don't want to add upstream build variables in every case where they'd make things more convenient for someone, since that could get out of hand quickly.

how to make the job smart enough to call back

Yeah, my expectation is that whatever's on the Jenkins side needs to know about Phabricator, because it needs to call harbormaster.sendmessage to report results when it's done. So it seems like the job has to be some-harbormaster-aware-build, and like it should be able to look up the repository name without undue work, as it already needs to know how to call Conduit.

Why is the approach used by Uber's Jenkins/Phabricator Plugin (which does not require repository.name) unsuitable in your situation?

Since that sounds possibly plausible, I'll confirm that timeouts end up looking like this in the UI, and repurpose this for "make timeouts readable to humans" if they do. I can dig into it some more if that turns out to be a dead end.

You control that API though, right? And could conceivably expose /harbormaster/job/{repository-phid}/ or whatever?

If diffusion.search existed, you could call it with repository.phid to pull the short name, callsign, ID, etc. Would this be sufficient?

Also known as the far more hilarious CURLE_OPERATION_TIMEOUTED.

This may be cURL 28, CURLE_OPERATION_TIMEDOUT. We have a 60-second timeout on this build step. Is it possible your server requires more than 60s to acknowledge the initial request?

That is, it already supports subscribers, the field just never got built in the UI.

We probably will build this sooner or later since it's free when Countdown eventually swaps to EditEngine.

Sounds good. I'm going to close this out since we don't plan to pursue the particular rule it describes and I think other related work is already covered elsewhere.

After D15427, this should be pretty clear for "Land Revision".

Importing SVN repositories as single repositories is recommended (Facebook's had several million commits in 2011, IIRC).

This hasn't happened again and I think it's less reasonable to expect it to work in modern Phabricator.

I think this was resolved at some point -- this is the behavior at HEAD, which seems broadly reasonable:

See also T2225 for a concrete issue caused by showing enormous numbers of paths (unbearably slow page loads because of the raw wire filesize).

This was fixed a couple of years ago in D4730, and works fine on the modern LLVM install: http://reviews.llvm.org/rL170845

After D15424, arc fails when failing to push the staging area.

I've marked D15424 as fixing this, although I don't have a detailed understanding of exactly what goes on in the git protocol and which heuristics it is using. In particular, I haven't been able to trick it into doing too much work locally (maybe it also looks at parents?).

This is on a daily cron, I think you missed the update by a couple of hours. Link works OK for me now.

Hi! How can we reproduce this behavior?

Please describe the root problem you're facing when requesting features. See Contributing Feature Requests and Describing Root Problems for details.

Thanks for the report! This was a bug.

I believe this wouldn't solve your problem: I could add two files, A.c and B.c, and add a header to only one. This would pass the rule but fail what you intend to enforce, I think.

oh, you also have to put an interface on the device in order to bind it

Create any device, create any service, bind the service to the device, then click "Details":

Drydock and Almanac are now available in the cluster. Here's a rough guide to configuring them -- I'll turn this into something formal once things work a little more smoothly.