Is this an example of "title art" or is there something better. I seem to think there was an actual header, but maybe not.

OK, Feature request filed here: T11158

I've deployed this and configured this server to use AES-256-CBC, although I haven't retroactively migrated existing data.

fair enough

We don't feel it's a good use of time to build out hypothetical features. The main reason is you're asking us to build something for a case that's never happened, and may never happen. We'll always likely have something more impactful to spend our development time on. Even taking this as "Wishlist" essentially means we'll never get to it in a reasonable timeframe.

I'd like the UI to not offer things which don't work - I have not tested Mercurial and SVN hosting and given that I've done nothing to make them work I imagine they don't

Is this actually a problem or are you just anticipating users will do this?

We can't reproduce this and haven't seen other reports of similar issues (including from other installs of greater size and complexity), so we have no way to move forward on this.

Bookkeeping; there's no longer an external driver for this.

Just bookkeeping; this doesn't have an active external priority driver.

Just bookkeeping, this doesn't currently have external priority.

Pulled and working! Thanks a lot!

This should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.

T11044 makes this both more relevant and somewhat easier.

"Autoclose" and "Track Only" configurations are limited to branches, and do not account for arbitrary tags/refs. For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future. I'd ideally like to replace autoclose with "fork" (T10691) rather than introducing tag(regexp(...)) or whatever, but that may be a long road.

To revive deleted commits when they are re-pushed, I think it is sufficient to ignore deleted commits when filling the discovery cache (PhabricatorRepositoryDiscoveryEngine->fillCommitCache()) and allow recordCommit() to detect existing commits and revive them.

Current state of the world after D16108 is:

Thanks for the report! This should be fixed once D16128 is reviewed, likely later today.

Thanks for testing, that's quite helpful.

I don't see how Herald rules are related to the provided "example use case" (maybe because it's unclear to me what "MUST acknowledge" actually means). Maniphest's advanced search already allows to combine "Created Before" and "Updated After" to address that "common need" - no Herald needed.

In T8510#179818, @epriestley wrote:

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

We have a large user base using various install locations on their PC's. The issue has come about following a recent upgrade from a 2015 version with more than one person affected.
If you look at the code I cant see why you would need write access - it is just processing path strings.
Anyway I have moved the install to your suggested directory but with no change to the fault symptom.

Another example use case: the ability to perform advanced searches based on report history criteria and to send "whines" (as on bugzilla) is needed for any project that wishes to join https://bestpractices.coreinfrastructure.org/ , namely the criteria:

The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
The project SHOULD respond to most enhancement requests in the last 2-12 months (inclusive). The project MAY choose not to respond.

On second thoughts, the flexibility of a Herald rule may already be better for me, as I want to filter out Merge Commits from auditing (at least when they are merged by an Owner), since the individual commits that are merged already have their own audit.

As someone who regularly uses Arcanist on Windows, I can't say I've seen this issue. You should try placing Arcanist in a writable directory, like C:\Tools\Arcanist. Installing it into "Program Files" is probably not ideal, as that's not a writable location.

Yeah, this is a known bug with aborting builds. It doesn't actually functionally impact anything (you can still restart the builds later, etc.)

In T11153#180624, @epriestley wrote:

You can determine both of these from the harbormaster step dependency tree.

Today, yes, but not if the tree includes custom build steps which allocate resources or if we add "if <condition>, run <another build plan>" or "foreach <item> in <artifact>, run <another build plan with 'item' as an input>". I think these capabilities are probably more interesting than being able to automatically count how many resources a build needs is.

We could do this when a plan is predictable, although an automatic lock acquisition scheme could fail in cases where an explicit one would succeed: for example, when a plan is edited, we may change discovered lock order from "A, B" to "B, A", and builds on the new version of the plan could deadlock with currently-executing builds. If both versions of the plan acquire locks explicitly builds will be able to survive edits.

Generally, I think resource autorelease (using @hach-que's rule) is probably the shortest pathway forward here. You'll still have a fairness problem, but you should get better utilization from the pool and be deadlock-proof on "A", "A" type acquisitions. This also tends to trigger less adjacent work than new resource types would.

Being completely fair also means we must execute without parallelism, because if we start position 2 without waiting for position 1 to finish it might win, and this could keep happening forever.

The expectation is that allocation should generally be fair ("first come, first serve") when no allocations fail.

It's causing a lot of pain mostly because we don't have good visibility into it happening, and we don't have any good way to react to it once we get close to fully saturated.

You can determine both of these from the harbormaster step dependency tree.

You don't really need an explicit release lease to solve this problem. Nor do you need an explicit locking system for resources. You can determine both of these from the harbormaster step dependency tree.

I'm planning to do this:

See some prior discussion in T10081, which I'm going to merge here.

@chad some of your commits are affected too, for example rP695f0b09b23761c813b015c2b62075cbdee1de59, better if you add for example a Ref T99999 ;)

I know you have focussed on the missing background, but I'm not overly fussed about that. But I am surprised that the commit subject shown twice in a row, once truncated inside a table and once not, is anything else but a bug.

@skundam this is not the expected way to get support. Please see Support Resources.

Another, very legitimate example, would be diacritic characters in localized README (or other) files. Until UTF-8 support is not present in text linter, i simply have to disable linter for files that have words like "żółć" in them. Plus using ¯\_(ツ)_/¯ in doc would be beneficial to some 😉

I think this also increases the chance that users accidentally disable or misconfigure (e.g., by misusing Match user) administrative sshd by requiring more extensive changes to its configuration. Users locking themselves out of the host is the worst outcome of a configuration attempt by a huge margin.

I know I didn't retrieve all the info you asked for, so let me know if you want to see anything else or want me to decode the base64 email body.