I would say, definitively. 'xxxxx' looks more like a placeholder for me, but that might be a personal preference.

This is fine technically, but I'm hesitant about introducing it because it makes the issues in T6522 worse in some sense. That is, this field really means something like:

If we masked with ***** instead of xxxxx, do you think that would have been more intuitive?

I am also affected. Is there any known workaround?

So, the information is just masked but really present in the real command call? The ssh man-page states what the options before the xxxxxs mean, I'm just not sure if the call is right when the information is masked. E.g. the clone call...does phabricator call with git@phabricator... or with the username provided for the ssh connection. anyway. Is there a log where the real command is written? Why is it even masked here?

the -l xxxxx is your configured SSH user, the -i xxxxx is the path to your configured SSH private key (it's written out to a temporary file).

Like, is "Students" a repository and not a project? Can you put "Students" into a project and filter open results that way? Where do repositories come into play?

How does grouping by repository solve that problem?

That data doesn't exist unfortunately, so it wasn't able to be migrated. You shouldn't see that on current badge awards.

I've got this on most of my Badges on the profile page (not here, 2 local Phabricator installations):

oh man that UI is old.

On CentOS 6 here using Webtatic PHP 7.0 with apcu. No apcu-bc available. I get errors with apc_sma_info() not found when trying to access the phabricator webpage.

So I think I can lay the groundwork here. My plan is to:

Probably go with data driven. I don't think these need to be sprited, but should probably inline CSS (base64) with celerity? I don't think these will be large enough to need to be in an image sheet.

I'm not completely opposed to ever changing this, but I think there are pretty good reasons for the current behavior.

This report isn't actionable. Feel free to file a new one that is:

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Basic support to (hopefully) support svnsync is now deployed. The Herald stuff would be nice to have eventually, but we don't currently have any real use cases for it.

From T10610, this can reasonably occur in arc unit subprocesses.

Sites eventually got split out (T5702) so that's no longer an issue, but this still isn't really straightforward. We do a lot of object loads which need some real viewer (blog, post, other adjacent posts, author, subscribers, object references in remarkup).

This still hard?

Closing as Resolved in general. T6299 and T4936 are already in the system separately.

(I don't know if this is the exact same bug, but we'd fix them both in the same pass)

Nice! Thanks.

I don't know offhand, See T10978, we have a lot of cruft in Audit that just needs tossing out.

Never noticed that before? Is this specific for Audit?

This is our expected use of Flags. They already exist on most objects, and users can build/query/sort them as they like for whatever reason.

Yes, that totally makes sense to me (and, in fact, that's what I suggested by teammates do), but even an ability to use Herald to automatically flag an audit based on comment activity would go a long way here.

Some relevant discussion in T1112, although it's more Differential-oriented than Audit-oriented.
T5722 is also probably related.

Some more info I dug up:

• There are 2 commits that appear to have flipped comments, i.e. the comments that appear on audit1 actually apply to audit2 and vice versa.
• These commits are sequential and were pushed simultaneously (i.e. the author made multiple commits on master locally before git pushing them all)
• In both cases only comments made by the author appear out of place.

I was picturing this as more of a tool to help the author keep track of things that may require attention rather than an auditor to verify that something is done.

I was picturing this as more of a tool to help the author keep track of things that may require attention rather than an auditor to verify that something is done.
This also allows for a workflow where a comment is made after the audit is closed that is not worthy of reopening the audit (and potentially by a 3rd party). And it could be both "I'm late to the party and I have input" kind of scenario and "I'm an intern and I have a question about this change 3 years later"

That's my expectation if something is accepted. That the author is trustworthy enough to follow up if needed or ignore if it was just a suggestion.

That almost works. The problem is that as soon as the audit is accepted it fall off of everyone's radar and there is no visibility into the comments an auditor may have made.

This doesn't sound like a desirable solution to the problem. If something requires addressing, raising a concern is always the correct action. If it's not an urgent issue, but the author wants to address it, they can flag the audit for themselves as a reminder to follow up. Is there something about the core problem maybe I'm missing?