• D14849 should fix messaging around "Create Subtask".
• I'm likewise unable to reproduce the original issue at HEAD, so I suspect it may have been fixed elsewhere. If anyone has repro steps that work at HEAD, let us know.

I'm just tracking this in T10004 now, there were a couple of other reports kicking around but it didn't make it onto the list originally.

This report does not include reproduction steps that we can use to reproduce the problem. See Contributing Bug Reports.

It doesn't make sense for "Lease Working Copy" to not provide a working copy.

You can probably set it to "0" to achieve the same effect, but this is a bug and I can reproduce it locally.

See https://secure.phabricator.com/book/phabricator/article/drydock/

This will be available in a future repository.search method, via T7715. See here for some discussion:

This is far outside even the far-future scope of Harbormaster.

In T9905#150315, @nicolast wrote:

I lost the preview (after a code update) while creating a new task on Maniphest. I it possible to restore it?

D14846 should fix the package case, but I'm going to leave this open for followup work: Files, Pastes, Maniphest should get indexes; and we should replace the powerful systems in Projects and People.

As general infrastructure cleanup, I would like to split the existing SearchEngine and DestructionEngine components apart...
As part of this cleanup, we should also fix T9890.

Why do these plans need to run sequentially in the first place?

Use spaces, a positive "open source" project or custom field, make "Games Project" public, or use a public negative project which is a companion to "Games Project" (Herald rules could enforce that it was added when "Games Project" was added and removed when "Games Project" was removed).

This is expected. Queries using projects you do not have permission to see are not valid, and do not return results.

I don't think it's helpful for the withMemberPHIDs() case. Here's a specific example:

Quote shell arguments which contain spaces or special characters. This flag behaves just like git commit -m ..., svn commit -m ..., and hg commit -m ..., and the quoting rules are the same shell rules used by every other shell program.

See also T5267. I found that task by searching for "translatewiki" in the global search.

This is the current intended behavior.

A technical issue I'm running into is that there is pretty much no realistic way to implement $project_query->withMemberPHIDs(...) unless we already have a computed view of effective memberships.

The plan in T3670#149755 has one potentially odd implication: if implemented naively, you may not be able to see all the members of a project.

We haven't seen more of these for a few months and I've been more consistent about tidying them up so I'm just going to close this out, but let us know if anyone catches more of these.

I've updated the description, but I currently expect to promote these changes next week.

@nickz I believe both issues are now fixed at HEAD. Let me know if you run into anything else.

Okay. You can implement the behavior you want like this:

I would expect 4 of the builds to fail as they can't allocate more resources.

There's no technical reason for that, either, although it probably doesn't make sense to raise it in advance of just fixing this properly.

How would you propose Drydock detect that it should fail if the situation is a legitimate deadlock that can not be alleviated by cleaning up resources?

So you'd suggest that we encourage Drydock users to configure limits in excess of available resources ("not wear a seatbelt") to improve error behavior when they configure a deadlock ("fall in the ocean")? If so, wouldn't it be better to simply remove the limits entirely ("uninstall seatbelts from cars") so that they can't accidentally configure a limit with bad behavior?

I've reproduced the first issue with the lease breaking but not being released. Here's what I did:

If you drive without a seatbelt, it will be easier to escape from your vehicle when it becomes submerged in the ocean.

For example, suppose we have perfect resource reclamation and reuse algorithms which always instantly destroy a resource the moment it is no longer in use.

The recommended solution for T9875 is to set a limit lower than "available disk space / size of largest repository", which reduces it to this deadlock issue.

Broadly, two issues here: