The Gmail/ICS integration seems to actually work OK in practice, here's an event from this install working (modulo some stuff like us not exporting a host/organizer yet):

This should be fixed in HEAD of master. Thanks for the report!

We can probably just use the merchant name for now. I could maybe imagine some "International Business Machines, Inc" vs "IBM" stuff down the line, but no immediate issue for "Phacility".

...and here are foreseeable issues with this mess occurring in the wild:

Broadly, I want to avoid implementing things that don't have good technical justifications.

OK I imported some real great events:

Is "GitHub-specific OAuth" just normal OAuth with client_id / client_secret as parameters instead of in an "Authorization" header? The GitHub OAuth documentation seems to suggest passing these as parameters, too.

I think the textarea predates using JS magic to make "copy" work. I think we could probably remove the "disable highlighting" mode now; I can't really imagine any legitimate reason to intentionally disable it in modern code, except maybe not realizing that "copy" will work correctly via magic.

I don't think we have a "client password" in this case -- I believe that refers to a mode that no one uses for anything (well, maybe a mode that Concourse uses, I guess), where the flow is actually handling normal user passwords?

We can, but all styles need to be inline. DifferentialInlineCommentMailView is an example of an arbitrary-HTML-generating rendering class used in mail.

Calendar is a prototype application, and we don't accept bug reports against prototypes. See User Guide: Prototype Applications and Contributing Bug Reports.

See Contributing Feature Requests for a detailed breakdown of what a feature request needs to have before we'll accept it.

I'm going to merge this into T10510, which discusses improving Harbormaster error behavior.

@pingpongboss, in T11787 it looks like you actually want to wildcard the repository names, not the paths?

I'm just going to "fix" this by just preventing you from hiding/locking/defaulting these fields, since it doesn't seem useful to create a "New Event on January 3, 2013" sort of form anyway.

D16752 was approximately the same thing but I think this is a little complicated -- both in general, and for recurring events. I'm also not really sure this should use the trigger system at all.

If you do Merchants, you could add sendFromEmailAddress or whatever and maybe shortNameForEmailSubjectLines (perhaps with less-awful names) and I can hook them up at some point so this:

I guess the Merchant version would be businessAddress or something since Merchants aren't normally billed.

I think we could reasonably do this:

An instance needs their own address (and some other information) on the invoice for tax purposes:

It looks like the underlying issue (T11469) was resolved through configuration changes, so we don't need to go any further here. We are writing this log now, but it could use more work eventually.

Another instance was reproducing this more frequently/reliably and reports that they're no longer seeing issues, and I haven't been able to reproduce it myself since the configuration changes. Presuming we're in the clear now, but let us know if you see further issues.

I think this is actually a bug between several of the 300 different pieces of scroll magic we have on the page.

I can't reproduce this by following the steps you describe. Here's a screenshot of this working properly for me:

In almost all cases, it's within a second or two of the push.

I'm going to merge this into T11330, but note that you can already do this via Harbormaster, as this install does (we build via Drydock, but you can run a "Make HTTP Request..." build plan instead).

D16744 should also improve SSH performance slightly, with a larger impact on larger instances.

This may have been the "MaxStartups" directive in sshd; if so, a partial fix is currently deployed (raising the limit on application load balancers) and a more comprehensive fix will go out tomorrow morning (also raising the limit on repository shards).

Awesome, thanks for following up. Let us know if you run into anything else!

I do not plan to ever let you reorder milestones.

This has been live for about two months without any substantive issues arising.

I don't plan to implement the rest of the feature request. Assuming drag and drop works correctly, I think this operation (reordering panels) is rare enough that using it is reasonable without introducing the additional complexity of duplicate controls.