Remaining work:

D20947 does not implement "Author's packages" as a "Commit Content" field, nor as a "Commit Content (Hook)" field. The reason for this is that getting the modern authorPHID in both cases is somewhat complicated.

The logic here appears to be that gc.auto is set to some value (by default: 6,700). If the number of loose objects exceeds this threshold (technically, if the number of loose objects in objects/17/ is more than 1/256th of this value), it triggers a repack (in a comment, git repack -d -l).

See PHI1613, where an install hit this warning (and resolved it by running git prune):

The issue in PHI1605 resolved itself without apparent intervention, presumably as a result of changes on the CircleCI side. I can't find any release notes to shed any light on things, but this is no longer time-sensitive.

See also https://discourse.phabricator-community.org/t/storage-upgrade-failed-class-phutilauthadapter-not-defined/3468.

See T13478 for followup.

I'm also still able to reproduce this specific variant of things, so it looks like I was too optimistic about T13462 covering this in at least some cases.

A similar issue occurs when the "Visible To" control wraps with spaces enabled. To reproduce this...

This should be fixed by D20943. Note that "Mute" in this context mutes notifications about edits to the object (e.g. "Alice renamed rule Hxxx from X to Y."), not notifications sent by the rule itself.

This went through cleanly.

These changes seem to have stuck.

I thought this was some kind of complicated mess with the regex on line 420, but it's actually an issue with this:

• Also move the Porter stemmer.
• Ran some search queries.

(Since a full implementation here will imply that removing a custom field from configuration may "unmention" an arbitrarily large number of relationships, and we can't easily do that inline or at display time, the ultimately implementation would likely include a more robust version of this script.)

In PHI1602, I proposed a script to "reset" mentions on an object. The use case this serves is:

If systems with no binary named python are reasonable to expect, and it sounds like they are, this is fine as-is. I've added you to Blessed Committers so you should be able to land this change yourself (check the project description for some guidance), or let me know if you run into issues. After this lands, I'll land a followup in arc anoid to test for a python3 and emit a friendlier error if it isn't present.

In jira 8.6.1 settings are now in:

• Administration → Applications → Application links

It's possible (and common) to write code that is both valid Python 2 and 3, like in this case.

This page intentionally has a no-Javascript, no-drag-and-drop upload form for users who use obscure Linux window managers that don't support drag and drop.

This is almost certainly fine, but I don't actually have this bleeding-edge far-future version of Python installed on my stock Macbook (macOS Mojave):

If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.

Last follow-up -- no, it was not a custom policy. The log of changes to the Project configuration show that the original setting for the edit policy was indeed "Project Members", which seems to indicate that Phabricator was incorrectly preventing new members from editing the Project.

I was unable to reproduce this with a new Project, which makes me suspect the problem isn't a bug in Phabricator. I suspect the Project that was not editable *actually* had a Custom policy with specific users added to it, rather than a "Project Members" policy.

I ran into this issue today as well. The context was a Project created by a regular user a few months back. He added himself and one other user to the Project. He also set the edit policy for the Project to be "Project Members." A few months later, a couple of other users were added to the Project, but neither of them could edit the Project (all links in the "Manage" UI were disabled, can't create milestones, etc.). The users who were in the group when the edit policy was set were still able to manage the group. One of them had to change the edit policy because the newer members of the group could not.

See also PHI1594, which wants:

See also PHI1579.