Can you see the repository? (PHID-REPO-rgnn364lembo2emt5622)?

This is in reasonably functional shape for ambitious users. There's some documentation now:

Probably not, but it seems vaguely nice that i18n extract doesn't need to know anything about the directory structure, and that we can put pht() in externals/ as a local patch if we need to clarify some error or something.

@Krinkle: I can't come up with a reasonable way to fix the height=300 comment preview case unless we render the element entirely on the client or relax the WMF constraints. I think the WMF constraints are excessively paranoid, but it's moot since you're the only person complaining about this and you're on the WMF install, so adding a "[X] Use less paranoid caching that doesn't flicker all the time." option wouldn't fix the problem for you.

• With height=300, yeah, it's going to be a flickery mess.
  • Without height=300, it's a flickery mess in Safari only, in the last few weeks, as far as I can tell.

I'm pretty sure the preview case is recent (last couple weeks) and I don't think we changed anything, but I haven't hunted down what actually did change. My theory was that it was a change in Safari behavior, since I don't see this behavior in Chrome and I first observed it after applying an OSX update. Are you using Safari in OSX?

Some discussion in, e.g, T9028, but we don't plan to ever actually delete these commits. They may have comments, audit status, meaningful relationships to other objects, builds, build artifacts, etc.

This is because externals/stripe-php/lib/Stripe/ApiRequestor.php has this on line 357:

The action is always available right now because it makes testing (particularly, testing things like "does it do the right thing when the revision is already landed") easier, but I'm going to require "Accepted" for v0 of this, which will indirectly disable it for landed ("Closed") revisions. We'll probably relax that later but it seems like the right place to start from, at least.

After T182, web-landed changes tend to leave local branches around since we never run any code on the user's machine. These are handled reasonably by arc branch, but having arc cleanup clean them up (or have an option to clean them up) might be nice.

Seems educational!

arc land already does this.

(If that sounds wrong, I can try harder to repro this.)

Specifically, I think this was only for steps created prior to the introduction of the "Other Working Copies" field. New ones should work OK without specifying additional working copies.

I'm generally imagining we'll get something like this in the Blueprint configuration:

As a workaround, editing + saving the step should populate this with an empty array. But we can be a little more defensive in the actual implementation.

See T5000. I don't plan to implement this feature as described.

Cool, glad to hear it! This is, at the very least, something we could document better. I don't think the documentation currently mentions that inlines are even a thing, much less describes the porting behavior or the rationale for it.

This feature is always going to be imperfect, but my personal experience, at least, is that something like 80-90% of inlines port somewhere reasonable (the code is still the same, or nearly the same), and I understand about half of the rest of them from context, and can click the "Rewind" button for the remaining few to see what the author was talking about if I don't remember. There are also cases where we can improve the behavior without needing to solve any hard AI problems, see T7870 for the ones we know about (it's possible that whatever you hit here is a case we could improve).

Okay, I think what you're seeing is an inline which has been ported forward. This is a feature, and an expected behavior. Here's an example of what it looks like.

Maybe it's easier if I try to follow your instructions. Here's what I did:

I have reviewed "A".

Update with "B".

You can probably use rGITTEST, but just copy/pasting some random diffs into the web UI is likely sufficient in this case too (no special behavior around inlines should get triggered). You're recent enough locally that you shouldn't run into any compatibility issues.

In particular, inlines are bound to the exact diff they are left on ("line 17 of changeset 28942 on diff 1842"), not a mutable location like "line 17 on file x/y.c on the most recent diff of revision 293". For example, you can go make comments on older diffs, which would not be possible if we didn't bind them to specific changesets.

This is not T4768.

I think there's a reasonable chance we'll build a dedicated "Manual QA Workflow" / "Runbook" / "Preflight Checklist" application some day, but I'd guess not before 2017 unless things change a lot. If we had this application, you could embed workflows into tasks or other documents using {...} syntax and check them off as you worked through things.

We don't see this on this install:

The SSH stuff should work fine. I don't anticipate supporting the HTTP stuff.

We had a very slow week and haven't made much progress here. There is a new list view and some new, more reasonable UI. We landed our first production change with this mechanism.

There's some usual magic on this dialog to try to make sure the "you looked at the secret" transaction is shown to you when you close the dialog to make it more obvious that your view was logged.

I guess I'm sort of OK with letting you make mailing lists administrators so they can pick up policy stuff. This is definitely pretty silly but maybe not only silly, and wouldn't hurt anything except for the other issues.

I'm likely to restrict pause/abort but leave restart broadly available, since engineers generally won't gain anything by restarting enemy builds (it causes them to take more resources) and I think there are legitimate reasons for innocent bystanders to restart failed builds even if they don't have administrative/management powers.

(T9308 is the origin story of cat1 through cat3.)

Sadly, cats 1-2 were prototype cats showing a progression toward cat3. cat4 is a unique cat but I'm not sure it has the charm of cat3.

Since we haven't seen any other interest in this in the meantime (although maybe you have?), keeping it external is probably best for us -- it's conceptually something that we're comfortable with, but it's conceivable that you're approximately the only install using it. We'd be open to bringing it upstream in the future if there's more widespread interest/use.