I'm going to roll this into T13077, which will provide full access to Phriction via the API. In combination with Webhooks, you could mirror everything into some external read-only backup system or just pipe every edit to lp and stick it in a binder or something.

Mooted by the switch to prose diffing.

Rolling this forward into T13077.

We no longer offer free instances and I don't currently plan to offer them again, so this is moot.

We no longer offer free instances so tier growth is slower, and I plan to compact the tier in the nearish term.

We no longer offer free instances so I don't currently plan to pursue this.

We generally seem to have a reasonable handle on this after all.

So, in my case this turned out to be a well-known issue with git --mirror and the way pull-requests/branches are set up. I was able to clean up the issue for my purposes with this one-liner in the bare repository:

I don't plan to support this because it makes improvements to milestones which depend on them being ordered ("move to next milestone", automatic date ranges, etc., per above) more complex to implement or use. All use cases here seem to be addressed by "use subprojects instead of milestones", especially after T11036. I'll make the ordering adjustment described above.

I don't currently plan to implement this. I think T5474, T10333, T11036, and using the Maniphest list view with "Group By" address this use case to varying degrees (if you "Group By: Task Status" and then turn your monitor sideways, you pretty much get the desired result). It's possible we'll end up back here in the future, but since I'm not planning to scope this into T13074 I'm going to close it until those changes land and further use cases arise.

Workboards have offered access to multiple task creation forms for some time.

I think D18665 seems to generally have been satisfactory here, so I'm going to call this resolved until additional use cases arise.

This task is a giant mess with pretty much no remaining actionable use cases. See T13074 for plans. If you want some use case here included in that, file a description of your problem via support pact.

I don't currently plan to do this. At a bare minimum, T5474 may moot it.

Some of this is fixed; the rest of it doesn't have outstanding customer requests.

I'm seeing this currently on our brand-new phabricator install. git push --mirror worked for the first repository installed, but now on the second, this is happening.

When a blueprint uses concurrency-limiting slot locks, it currently just returns a random lock if it can't find a slot it suspects is free. This makes "all slots look fill, waiting for something to free up" ambiguous with actual collisions. It would probably be better to distinguish between these cases and make it more clear which one we're in.

After the patches above, I can't reproduce any bad behavior for T11495 or T10559.

I'm unable to reproduce this by following the instructions provided, at least after changes in T13073. Here's what I did:

After changes T13073, I am no longer able to reproduce this. That task has made some improvements and may have fixed whatever happened here.

My HoaxBlueprint does not implement activateLease(). This causes leases to be broken and destroyed.

Slightly more broadly: if the lease starts actually activating, we can't be sure that we can undo its state in the general case so we need to throw it away. But this failure (where the resource it has acquired doesn't activate) carries no such risk, and we can safely just throw it back in the pool. I think the only state we need to wipe out its its slot locks, which are easy to clean up.

Note that there's another similar scenario:

I just removed the setActivateWhenAcquired(true) for now without changing behavior. Next issue:

Alright, next issue:

Leases and resources don't use standard header UI tags to indicate status:

When logs span multiple lines, they are rendered as unreadable garbage messes:

When blueprints claim to be able to allocate resources but fail during allocation, we currently destroy the lease. I think this is likely too severe: consider an EC2 blueprint where the allocation call fails for some temporary reason (EC2 just fails, or we hit the account limit for instances, or whatever else).

In trying to plot a course through this, I'd like to try to sequence this so that existing issues get fixed first, then breaking changes happen afterward (maybe in the next release). Some of these changes (particularly, the CustomField-to-EditField change) will be significantly disruptive to existing custom code. (That change is also pretty straightforward and new stuff depends on it, so I'd probably start there if there was no compatibility concern.)

See T13072 for Harbormaster followups.

This doesn't really describe anything actionable.

This is something we could reasonably build now, but I think we're unlikely to build it without a customer request and an actual use case. Closing until those materialize.

In Chrome (Version 64.0.3282.140 (Official Build) (64-bit)) the inline comment buttons have a hot-spot for tooltips to party

See Planning.

Is there someone working on this feature?