These fields don't apply to other document types, and other document types have other fields which do apply to these results. It does not make sense to search all documents by, e.g., "Priorities". We definitely aren't going to pursue this as described.

T10486 is related; T6027 and T5214 are somewhat related.

T7190 has discussion of a similar case.

I think this isn't tremendously important for Countdown but should definitely be sorted out before we unbeta Calendar.

It might not be bad to always show timezones in email explicitly to deal with cases related to T3025 better (e.g., you fly to the east coast for a conference, get prompted to reconcile your timezone after T3025, and it may not be obvious that this also affects mail you receive until you return and re-reconicle back to PST).

With metamta.one-mail-per-recipient on, we can adjust this to the viewer's preferences.

I also may just restore this at some point to align with user expectation, even though I think it's a bad feature and we benefited on the balance from removing it.

T1258 might be another attack on this, not sure how much that overlaps things.

We have a large, and growing, set of teams that would like to get CCed whenever a review is created in a repository they work in.

Yeah, pretty much the same for me. I believe "Open Revisions" has a small population of fans and "Local Commits" may get more useful eventually (e.g., after whatever happens with T1508) but I think we're on fairly firm ground shoving these into tabs.

I spent some time on this, but this ends up being more involved than I thought because there's a lot of weirdness around how actions and property lists interact, so this is probably blocked on making all UIs which use property list tabs and actions switch to the two column view.

To provide some context, until recently, the API was in bad shape. Basically, the first time we wrote an application we'd maybe write some application.whatever methods, which shared some code with the rest of the application but not all of it, and then the API and application wouldn't always get changed in the same way. This resulted in methods like repository.create which can do maybe 20% of what the web UI can, does it in different, inconsistent ways, and edits made by the API might look or work differently than web UI edits. In bad cases, they'd even do different policy/permissions checks. This caused many many problems for a very long time.

Changes like T10569 should probably happen first. This is likely to be very complex, and is probably not a good task for a new contributor.

This request doesn't describe a root problem and we don't seem to be making progress toward one, so we can't move forward on it.

No, we're not open to implementing this as multiple separate select controls. We don't really have a UI in mind that we're happy with, but we have several we're less unhappy with than multiple select controls (leading contenders: single optgrouped select, alternate actions menu for workboard actions; possible contenders: visual table-layout control, select per-project in a dialog).

How do you imagine Phabricator learning about the existence of new external groups? Just polling a list of every group in LDAP every hour or whatever?

Like T10622, I think this is reasonable to expose as an extensible behavior, but it should wait for T10329 so we have better tools to support it.

I think this is generally reasonable but would like it to happen after T10329 (roughly, "proper extension infrastructure for arc"), when we'll have the tools we need to better manage versioning and deploying client changes.

Can you describe the root problem? What kind of rules are these? Revision rules?

You can already do some of this: "Land Revision" itself is added to the menu via DifferentialLandingActionMenuEventListener. You can use listeners like this to extend the menu.

I've updated D14284 + D14286 + D14288 for the new API and rebased them onto modern code.

It seems that tag builds do not support build_parameters. We need to pass parameters, so this is blocked on them again.

• Once D15499 lands, this is available as a prototype.

According to CircleCI this really truly works now, so I'll see if I can push our integration forward shortly.

I renewed the certificate and launched a new VPC load balancer, which can forward port 22 traffic:

We use secure.phabricator.com for both HTTP/HTTPS and SSH traffic and ELB can't currently forward port 22 -- except the docs now say EC2-VPC LBs can? So I need to figure out what's going on with that.

I think the remaining part was "show a lot more versions of different things", but I can't immediately think of cases where that would have helped us resolve something faster.

CORGI will fix this and clearly it is too hard for me.

That one worked OK, yell if you're still seeing an issue?

Test: User Guide: Prototype Applications

Oh -- I misunderstood. The issue isn't that we're getting invalid markup or emitting markup in a text context, but that the link is relative.

This is probably very easy to fix, let me spend 3 seconds on it.

Yes, Phurl provides URL shortening. U10 is the root object providing ((prototype)).

The technically-functional-prototype code is live on this install, now:

This isn't really the same as T7013 or T9161. T7013 was intended as a pure infrastructure optimization, I just named it really badly. And even if we had the fanciest rules imaginable, T9161 wouldn't help, because this case is currently unknowable.

Sorry, I picked a really bad name for it originally.

This task has nothing to do with any user-visible behavior and is purely a performance/network optimization, despite all the discussion about batching emails here. :)

You can use the default syntax (+x +y) to perform an AND search explicitly. See:

(There is also a different type of cache from <object hash -> metadata> we could build in Git, but that's kind of a lot of work.)

In SVN, we can use a different icon because we have prebuilt cache of file types (and must have this cache for other reasons, and can build this cache efficiently, and SVN distinguishes between binary and text files).

Please tell me if you would merge this improvement if we implement it.

Quick update:

One issue which we'll hit eventually is that git-lfs doesn't currently support pushing to remotes by URL, but we push to staging areas by URL:

Is there any chance that this feature will be implemented sometime soon?

No way for the upload API to say "no thanks, I already have that file"?

Why are users who shouldn't be changing priorities doing it?

See T10333 for plans to make dragging cards in sorted workboards more clear (and T8135 for additional discussion). Those UIs aren't as clear as they should be and we'd like them to be more clear.

"project" there just the noun, not "Project-object", but we could probably pick a different word to avoid ambiguity.

Quick progress update:

D15483 changes the constant to 47 (15 window size + 32 for gzip + zlib), which should accept and decode the broadest possible range of inputs. If this somehow breaks something, 31 (15 window size + 16 for gzip only) is probably the next thing to try. See that change for discussion.

This is probably a variant on T4551.

For searching across all types of everything, I lean toward adding an "Insert object reference..." button to the header which pops up a search box (similar to the "Edit Blocking Tasks" box) instead of trying to trigger on {T... and such. I think this is a lot friendlier for new users, and we'll have a bit more room to let you filter/customize the query, and this operation is probably not so common that it needs to be triggered on a whim inline. For power users, we could maybe add a keystroke (say, Ctrl/Alt + @) or something so you didn't need to actually click the button.

Here's a diff to make bin/storage adjust always run ANALYZE on every table after it makes other adjustments, but I'm not really sure if that's actually helpful or not (e.g., from the documentation, it sounds like the good analysis can be immediately overwritten by a bad one in some cases?):

I think so. Sorry for the originally misleading claim.Sorry for the originally misleading claim.

Oh, I might not have made subscribers actually do anything, I don't remember. They definitely should, though, even if they don't yet.

Well, the docs suggest not doing that:

Should we get rid of the <commitID, isDirect, changeType> key, then?