(We could theoretically fiddle with this and include some time constraints and stuff but I suspect this rule is already the best rule we're really going to get, given how contentious/subjective the subject is and how little complaining we hear about it, relatively.)

We don't show a specific amount of history: we show all activity since your last activity.

What about having the number shown be proportional to the total number of stories?

D14452 and similar seem nearly certain to obsolete this.

See Contributing Bug Reports.

(I'd also like to be able to subscribe to Almanac devices/services/networks too)

We now have execute as well.

We might build this as a side effect, but there's been no actual interest in it.

We now have better behavior in general, and no other reports of this in a couple years. The underlying use case also isn't clear to me; build artifacts should be .gitignored.

They now sort by date and have some options.

This was directly obsoleted by the removal of arcanist projects.

The future of these pipelines in the upstream is server-side, not client-side. See T9530.

This hasn't really surfaced to the upstream in the last couple years.

I've done some work on this and I do intend to continue working on it, but have been somewhat time constrained as of late. The foundations for this task are already in place and many unit tests engines just need to be modernized to work with the .arcunit specification.

Haven't seen more issues here in several years.

This is now meaningfully achievable through Drydock as a repository operation, but we've seen very little interest in it.

We'll continue down this path, but I don't think there's much value in keeping this task around -- more modern tasks like T5447 cover the same ground more usefully.

We haven't seen further interest in this in several years.

No upstream use case in years.

See T1562 / T4171 for modern versions of this.

The use case I'm trying to cover is to create notifications for open tasks that are past their Due Date (custom date field that we use).

Presuming no one cares anymore.

Given the modern realities of support, I don't actually think we'd be better off by making it easier to submit stack traces. We also explicitly don't want surprise patches.

Pretty sure this is just a bug, auth and conduit auth have each gone through a major rewrite since the last time the log was touched.

Yes, see Paid Prioritization. Shoot us an email at contact@phacility.com if you'd like to move forward.

I conceptually like the approach you outline for --only-new.

I was thinking of changing arc lint --only-new to do the following:

Sniped!

Please see:

Yeah, I'm onboard with that plan.

(This is just a note for me to make sure I don't forget about it, I'll follow up here before we unprototype.)

Are you planning a fully specifiable merge command so we can run anything we want for merging?

running arc diff --update with an accidentally incorrect revision ID would be less likely to succeed if revisions were only editable by their author

I suspect T9132 will address this use case.

This was fixed as part of T9657:

accidentally updating revisions that aren't theirs

What's the actual error you've encountered when trying to add such a file?

https://secure.phabricator.com/book/phabricator/article/prototypes/

https://secure.phabricator.com/book/phabricator/article/prototypes/

• I cherry-picked this to stable (rP111c48b2).
• I deployed this fix to the Phacility cluster.

I don't think there's any way we can reasonably run pre-receive hooks from the test console in the general case. The pre-receive pipeline reads state directly from the underlying VCS, and much of that state is transient (e.g., we may read svn look --transaction <txnid> or whatever). If a user gives us a push log PHID to test later, we can't really rebuild most of the state.

I'm fine with giving this a shot.

Wasn't aware of this one, thanks.