In case the case of a limit being set, then yes, I expect it to fail immediately (and I expect them to fail until the resources drop below the limit).

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

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.

On the flexibility side of this I've managed to run into the 32 character callsign limit. We like long names? ¯\_(ツ)_/¯

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?

No, I'd suggest that Drydock fail (and clean up resources used by failed builds immediately) instead of deadlocking.

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?

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

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.

I believe there's another deadlock issue here as well though, say 10 builds start with the following plan:

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.

T9875 is different to this. This discusses leases being deadlocked, whereas T9875 is there not being enough storage space on the host to hold copies of all working copies + build artifacts at once.

Broadly, two issues here:

Custom fields (and paths, too) can now be read with owners.search and written with owners.edit. There's a description of a more complex edit (against paths) here, but the same general workflow applies to examining and updating custom fields:

I didn't tag it properly, but D14812 resolved this.

I think sth like the following would be quite common:

Sales
     -> Milestone 1
     -> Milestone 2
Engineering 
      -> Backend Team
            -> Sprint 1
            -> Sprint 2
      -> Security Team
            -> Milestone 1
            -> Milestone 2

From a purely personal/selfish perspective, the support workload the funny buttons generate seems disproportionately high to how funny/interesting they actually are.

I have no plans to pursue this anytime soon, but one of the goals of ApplicationEditor is enabling universal bulk editors, and I expect to pursue that and generalize bulk editors before implementing new bulk editor features.

I think you could treat them equally by having the parent project members be those of all the subprojects in both cases. I think it would be a valid usecase to change members from one sprint to the next (retaining the information about old sprints members).

D12692 is nearly the correct patch for this (and will support mentions, file embeds, etc., although currently not Fixes http://example.com/T123, which is parsed somewhat separately -- but that is also fixable fairly easily), it just has some tricky regex/execution order stuff that hasn't quite been sorted out.

Regarding the two use cases Engineering -> Backend && TeamX -> Sprint2:
I think you could treat them equally by having the parent project members be those of all the subprojects in both cases. I think it would be a valid usecase to change members from one sprint to the next (retaining the information about old sprints members).
All that's needed would be some magic upon project creation that uses the members from another project as a template (the last sprint or maybe the parent project as default).

FWIW, we have a script that uses arc patch --nobranch to "graft" someone else's working tree into your own working tree. We suppressed arc patch output entirely after enough people complained about "all of the branches its making".

Here are my diggings in the logs to determine how many diffs are problematic (there are 27)

cspeckrun@specktop ~/D/daemon_logs> grep -o -E "PHID-DIFF-[a-z0-9]{20}" daemons.log | sort | uniq
PHID-DIFF-2tkk6i73v4o32wqfqcsb
PHID-DIFF-4tnlystz7it5w44j7imd
PHID-DIFF-5i5uoael4eeuhdj5hsgw
PHID-DIFF-75mxqtmqo6f7xot6ciar
PHID-DIFF-7kwzsmaymdbdbxxo7lru
PHID-DIFF-c5qhg3kcivjarfwd2wek
PHID-DIFF-cptimb5cxdariuh4xufh
PHID-DIFF-eqo6o5le2phkdlflqyxu
PHID-DIFF-f5fbtt6ap6odesigjbmj
PHID-DIFF-fyfkn25bo6gtkutuepax
PHID-DIFF-fzyhpnm7eb6gkwlo42pf
PHID-DIFF-ghrwxjwtf7x7ngxyctfn
PHID-DIFF-hv7oxcttgnlksvixhya3
PHID-DIFF-ial33nwcdim4it3ne2pd
PHID-DIFF-irahpyhwfl4mkrvwpcpf
PHID-DIFF-j3ucrnpm6ytqhnb6yv4y
PHID-DIFF-lu3vilalrz6bl4e3aexj
PHID-DIFF-lvwde63gotffedkrmqlm
PHID-DIFF-nl2q7sybe77ydc3rnh2d
PHID-DIFF-o4ugvxgy3djdptvi5dn7
PHID-DIFF-pzrxnjtrm4hmbik4d7af
PHID-DIFF-rn3eaygvie4ylbxqxmdd
PHID-DIFF-rxuv3g5g3pibqq7o4gxj
PHID-DIFF-szgjp2bc6znknxaddesg
PHID-DIFF-vohgcadppoygmn3judfy
PHID-DIFF-yyziqbxidx575ey5b3w2
PHID-DIFF-zplnxsntawlxmhu7sag4
cspeckrun@specktop ~/D/daemon_logs> ls -l
total 294424
-rw-r--r--+ 1 cspeckrun  staff  120935264 Dec 17 23:12 daemons.log
cspeckrun@specktop ~/D/daemon_logs> grep -o -E "PHID-DIFF-[a-z0-9]{20}" daemons.log | wc -l
   45645

We should make sure to include mentions support too.

thx for deduping

er better example: T1023 v. https://secure.phabricator.com/T1023. Ideally both would be handled the same way.

Thanks for the quick fix.

(Confusingly, the help suggests that --whitespace=warn is the default and that warn does not fix errors, but maybe that's a version thing or maybe there's more config.)

warning: 1 line applied after fixing whitespace errors.

This is closely related to T6670.

Why do people are sad? I for one love to click "Set Sail for Adventure" instead of plain boriiiiiing submit. Quality button names are important for fun and profit ™️

"Submit" was always available in serious business mode, though.

The "Clowncopterize" button was a huge roadblock to adopting code reviews in Differential in our organization. The engineers refused to press it, opting instead of just email each other in the email Phabricator sent out when the Diff was created. Everyone was confused about what it did, and were too conservative to take the risk. We had to hire a PHP outsourcing company in Indiana to patch our deploy so the button instead displayed "Comment".

Tentatively, projects get new fields:

After D14811, here are the new behaviors:

Yes, it is possible and that is what I am doing. :] You can point to an entire different server if you want, but we happen to have ^/../other_repo since the externals are on the same server.