Aliased 'arc foo' to 'foo'.

There's no description of what problems this is trying to solve. I don't want to just add random fields in the hope that some will be useful; see Contributing Feature Requests.

I'll need to at some point go and clean these up.

• I believe username association works correctly.
• Assigning an email is already mandatory when creating a bot:

I don't plan Almanac to ever autoscale. Autoscaling would be via a new, non-Almanac EC2 blueprint (or similar blueprints, which permit creation of new host resources). I'm just going to merge this into T5544.

Perfect! This should be easy to fix.

I can reproduce the bug on what I think is a relatively up-to-date production installation.

You need to give us steps we can actually follow in a development environment to reproduce the issue. We can not examine database data, logs, etc, on the WMF install.

Here's what I get. Note:

I can't reproduce, those steps work fine for me on this install. I can click "Show Details" on the transaction above while logged out and get a dialog showing the details.

Here's my guess at how to reproduce:

This is very unlikely to happen.

In T9848#145894, @OCram wrote:

Hmm strange, I do not use any md5 function. I simply copied the ArcanistTextLinter and changed it to work with files containing \r\n line ends. Thats the reason why I do not know where the md5 function all or the variables come from ^^

D14589 should fix the immediate issue. I've also cherry-picked it into stable.

Context here is:

I think this is just junked up and I hadn't pushed this server when I claimed it works.

This is likely the next cause up the line:

I just saw this happen on this install (no metamta.differential.unified-comment-context) so my guess was probably incorrect.

Can you point out which parts of Contributing Bug Reports, User Guide: Prototype Applications and Support Resources are unclear to you with respect to this report so we can improve the documentation?

Yeah, consistency and like "attacker gets into your account and deletes all your stuff and it's gone forever and you are so very sad" and such.

We could probably just do unpublished for now and wait until we have a stronger use case for a real "archive".

Way better on my monitor now, thanks!

I am also fine with articulating meaningless corporate values.

Here's a super helpful photo of my screen :3 :3 :3 :3

Yeah, I'm using a Dell U3011.

I don't know how to reproduce this, either. This may fix itself as T9132 evolves.

Here's what's happening, in detail:

This seems straightforward to reproduce:

Drydock is also a prototype, see User Guide: Prototype Applications.

You are about 4 months out of date.

Cool, let us know if you run into trouble. I think it should be pretty easy to port any existing code which does generally transaction-like things, but might have missed something.

My initial thought is that we should maybe just parse strings in various "almost certainly time" formats -- rather than adding a special syntax -- like:

D14575 passes transactions to HeraldAdapters, so custom HeraldActions may examine them. The action will receive concrete, persisted transactions which have been validated, merged, checked, and applied. This will land shortly.

Problems with these events which you are exposed to:

Primarily, it only fires some of the time, per this task.

Fixed in HEAD (D14571).

Some more information:

Haha, no problem. Definitely not a big deal either way.

Ah, okay, I wasn't sure if "cool!" meant "approved" or "I'll look into it".