When filing feature requests, please describe specific problems:

This is opening up into some very deep infrastructure work.

D12337 for the policy dialog fix.

Add other protocols by configuring uri.allowed-protocols.

I'm maybe 60/40 on message being better than participants, but @chad might have stronger feelings. Agreed that it's not confusing to show a departed participant if their message is shown.

Although the behavior makes a somewhat-reasonable sort of sense when considered carefully, I'd personally expect removed participants to immediately vanish and would be equally confused about the behavior as implemented.

T5031 doesn't really need to happen first but we'd end up in a cleaner place if it did.

As it turns out, this is fairly messy.

We'll fix the bubble behavior. The persistence behavior is intentional.

Whoops, thanks.

(From a user point of view, at least?)

This is better than git-annex only because it works better on Windows?

Set policy.allow-public to true in your config, which will allow you to use the "Public (No Login Required)" policy setting. You can do this from the Config application on your instance.

We'd possibly be better off popping up $EDITOR for a description (or optionally accepting it from stdin or a file) and then interpreting mail commands in that description. That feels more flexible and consistent, and probably a lot easier to use.

See T4345, approximately.

Yeah, this is definitely motivated mostly by cowsay, we'd just get dot for free.

I'm vaguely concerned about installing dot (and cowsay) because it's possible that they include features which can execute arbitrary commands and compromise the security of a host. Mercurial had such a vulnerability recently, see D12112 for some discussion. It is is unlikely that dot or cowsay have such issues, but I suspect neither program (particularly cowsay) was developed with malicious input at the forefront of design considerations, and the more binaries we execute directly, the greater our exposure.

I think I removed an array_filter() somewhere, probably during T7731.

We're satisfied with the current behavior. If you're rewriting responses in a proxy, you should overwrite the header.

This is behaving as expected. We send the header with "max-age=0" in order to overwrite older settings user agents may have cached.

Can you describe your use case in more detail? See:

To better define this:

This is intentional. This is a login page, not a 404. We don't 404 logged-out users because we don't want to disclose the existence of applications.

We should try to emit a more actionable error message.

Yeah, give me about 30 days and I'll send you another one.

Yeah, publishing everything feels OK to me. Some of the stuff like lock edits and icon edits is maybe pretty fluff, but it's all so rare that it doesn't seem worth special casing.

Steps I've taken so far:

Mailgun's minimum Managed pricepoint doesn't make sense for us so I guess I get to learn about mail ops. :/

Mailgun got back to me suggesting that I check out their "Managed" offering, which is how I got in contact with them in the first place, so their sales funnel is currently looping back on itself.

A particular case where leaving is difficult is in the column, although trying to address that right now is probably putting the cart before the horse as I imagine we're somewhat likely to either get per-room menus or participant lists or both there.

A better description of this task is probably "Participant lists should have a meaningful, obvious ordering".

I also think "Leave Room" sounds pretty good if we have a reasonable place in the UI to put it. It's not immediately obvious to me that I'd leave a room by X-ing myself off the participant list, even though the interaction makes sense if you know about it.

Oh, there's a task for this. T7765 is closely related.

To define this a bit better, I'm imagining these components:

am not 100% sure why you'd want to resubmit in the 'environment side-effects' case.

The behaviour in this case, where changed patches get --update'd, and unchanged patches generate entirely new revisions, is surprising to say the least.

The specific behavioral change this implements is that Personal (not Global or Object) Herald rules which take a "Send me an email" action can override these user settings:

We haven't seen other interest in this and don't plan to pursue it in the near term. I believe deployment of client SSL certificates is exceptionally rare in the wild. Running Conduit over SSH (T550) might solve some of the same problems but has far broader acceptance.

I do think two possibly-reasonable exceptions are:

Oh, maybe it's sorting by "most recent message".

lists currently sort by join order

Yeah, we should probably remove this. T4103 will eventually allow global defaults to be set up.

I'd get rid of the "top query returned" behavior if we adopt this, to make things simpler. "All" would always mean "all", never "top query among saved queries".

Yeah, I'd make the app search be something like "Current Application" and it works like "All" if you're in a weird application like Settings or Auth or whatever.