For prioritization, I estimate we can complete this within 6 hours. It may all be straightforward and easier than that, but there are enough weird edge cases and UI implications that I don't want to commit to a best-case estimate.

Almanac Blueprints aren't mentioned downstream but I think are also a fairly good fit for this:

Yeah, I don't think this helps at all if there are 50 results, but I don't think we can do anything about that. Better solution is to fix the workflow somehow (nuance, subprojects, etc).

The original use case on the downstream task (https://phabricator.wikimedia.org/T234) was this:

I think users are probably mostly only using this UI to browse things anyway, so it's likely OK to "slow it down" a bit visually, since that could make it easier to navigate if we save users from needing to go look up information in a new window.

(Although we do formally support and have documentation for the the "import, then make hosted" and "copy the whole working directory into place" methods of repository import now, both of which skip the pre-receive rules.)

Disabling Herald there only disables the post-push, at-discovery-time rules, not the pre-push pre-receive-commit-hook rules.

My plan is to put an on-hover (always available on mobile) edit icon on top of the thumbs on the edit UI, similar to how the interaction works on workboard cards:

• We'll bring something similar to D11297 upstream.
• T6674 discusses an issue where some mime types (notably, OGG) may ambiguously be audio or video. At a minimum, we'll provide {Fxxx, layout=video} or similar to force ambiguous types to render as a specific type. This may not really be much of a problem, but if we don't have an easy, reliable way to automatically detect whether a given .ogg file has video we aren't planning to put a tremendous amount of effort into detecting it correctly at this time.

This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

Can you create a document on this install which you believe should have a table of contents but doesn't?

This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

Copying in some context from elsewhere:

This is conceptually reasonable, but likely years away. We ship no native code right now. Although there are many Phabricator applications which could take advantage of an optional OS client (for example, to make it easier to upload screenshots or access files) the pathway from where we are now to building one is a very long one, and none of these use cases are near the top of our priority list.

Please read Contributing Bug Reports carefully and make sure you provide all the required information, particularly reproduction steps (see Providing Reproduction Steps). Thanks!

Sure, let me split the subproject/workboard piece out and we can walk through it. (I may not get to this tonight because I have had a long day of Business Things.)

Would it be possible to prioritize part of this ticket? Specifically, the use case mentioned in T10627? We are also interested in the ability for members of a project being able to create subprojects without requiring global "Can Create" permissions for Projects (I thought that there was already a ticket for this somewhere, but maybe not?)

On the "public preview" use case I do think "--plan-changes + [DRAFT] in title + just let Herald triggers fire, if users configured them they can deal with knowing about your not-quite-perfect-yet changes" is fairly reasonable, which is part of why I've resisted pursuing this until now.

to avoid accidentally forgetting to pass an additional option in cases where you did intend it

Another possibility is:

We've never seen any real interest from other installs in a default preview-before-publish mode, and I'm not aware of any class of mistakes that users routinely make or wish to correct which this mode would aid in (if I was, we'd try to detect/fix them in arc diff so users didn't need to go to the browser). We've also never seen other interest in the annotate-before-publish use case. T949 is the only task in this vein that I was able to dig up, and focused on previewing the diff only. I'm not really sure what problems this mode solves outside easing adoption when coming from another tool which works like this.

As a sanity check here before I actually build it, is anyone who is interested in configuring global default settings interested in configuring any settings other than mail-related settings? Or is this just T9161 in an alternate form, practically speaking?

Competing translations are waste of resources and choice is not good for users.

I do not know what are you main concerns [with direct commit access].

I'm not sure how to describe it differently.

Commit objects are not GC'ed in Phabricator?

Deleting the branch first won't have any effect, since the commit still exists.

My general line of thinking is that providing a better idea of a "context" to arc unit (e.g., diff vs build) and letting it make a default decision about which tests to run (possibly including no tests) is probably the most promising way forward here. You could still override this context with some kind of arc diff --run-some-extra-tests flag. I'm not sure if hard-coding a small number of contexts or making them fully user-configurable or something in between is the best way forward. This is probably a longer-term thing.

We have a somewhat-legitimate technical reason for this behavior: when we compute which-packages-own(list-of-paths), we do so by splitting the paths into components and then querying for the components. a/b/ is the best database representation for this.

This was a legitimate upstream bug and I was able to reproduce it by following your steps, thanks for the report. D15971 should resolve it.

If developers generally don't run tests locally, is having arc unit do anything really valuable in your environment? That is, if you solved this by de-configuring arc so that arc unit did nothing, what would you lose?

Is this the same as T6522? I'm not sure where the last screenshot came from, I wouldn't expect an FF-merge + push to trigger another evaluation of Herald rules.

Great, glad things are working. Let us know if you run into anything else.

This appears to be stable and working properly, at least for the most part.

Does your configuration satisfy the conditions described in the documentation?

This service has no relationship to Apple Computer Wiki, and can not help resolve your problem.

This is because that credential is in a restricted Space so this is ultimately the same as T9771, I'm just going to merge it there. The actual Query looks to be implemented fine so I think this is purely a Space issue.

Thanks!

I think the largest source of concern here is the (1b) and (3) rules: we aren't willing to exclude translations from other sources, and we aren't willing to give anyone direct commit access to the upstream. But Phabricator supports loading translations from external libraries, so we don't actually need to resolve these issues.

This seemed to fix the issue:

From the server logs:

Phabricator version is rPe1ad312fdd2c570eeaacd3e02eda2142cc5d9849.

I think I have a pretty good guess about this one.

@joshuaspence, see T11010, I think. Not sure why nginx was 502'ing there, but should be fixed in HEAD.

Before I dig into this, is there any possibility this was a daemon running old code? I don't remember if I tested this explicitly and it could quite reasonably be an upstream bug, but the code at least attempts to check for this, and D15939 theoretically fixed issues with this.

We can also use weird implicit magic to try to resolve this. Here's a ruleset that will make everyone equally confused and unhappy:

I think that that creates some tension that I'm not immediately sure how to resolve:

We aren't really sold on this as a specific use case, but can give you a modern dashboard.panel.edit which will let you implement it. If there are weird followups arising from this (like difficulty managing the 300,000 transactions on the panel detail a year from now) we may be somewhat less sympathetic to them than we would be to a more on-label use case.

This is about two hours of work.