To prevent this, I plan to:

Here's the smoking gun from /var/log/syslog:

See also T5701 for bonus complexity.

This option should already be available from the UI. Here's a screenshot?

@jshirley, here's the issue we spoke about earlier.

Anyway, assuming this is a "freedom and flexibility" issue over a "perform only reasonable operations" issue, we're definitely open to implementing forking, but this is probably in the realm of prioritization with a nontrivial set of infrastructure and product blockers.

I think I'm still missing something here -- are users doing this?

In this case, does the branch contain reviewed changes, or just draft changes by multiple different authors?

I think these steps should reproduce the issue:

Root problem: To ensure quality software, I want to make sure that all reviewers accept a change.

I think that's just a rewording of the original description, and doesn't provide any new insight or context. It still focuses on a very narrow symptom problem (not being able to see individual reviewer status from the revision list), not the root problem.

T1279 is talking about the reviewer list on the detail page (/Dxxx), not the list page (/differential/). This was implemented years ago, so I suspect it isn't a duplicate, unless you're years out of date.

Thanks for the request!

D15545 should fix the infrastructure part of this, and make this error more clear by returning an explicit diagnostic error rather than a mostly-working string and a log.

Oh, I believe the actual issue is that the translations are variant on the wrong parameter. I think this is the correct fix (adding an extra array()):

D15544 (changing %s to %d) shouldn't be the fix for this -- %s is correct, because we want to render "1,234,567" if the number is large:

D15535 should completely fix this in all cases

u wot m8? havin' a go? havin' a little laff?

Specifically, the issue here is that we fetch and import branch heads, but not other refs, including tags. We also aren't totally consistent about which refs we import across hosted/imported repositories.

At a minimum, Herald, Harbormaster, Nuance, Phortune and Differential can author stories today, although not all of these stories currently render with photos. We should probably assume any application may author stories.

See also vaguely-related T8952.

This is now fully configured.

I ultimately don't think there's any really reasonable way we can fix this that doesn't have a cost and complexity far greater than the benefit.

This has been live for some time without any apparent issues.

We haven't seen further reports of this in more than two months, so I don't plan to mitigate it at the application level.

Presuming resolved by getPathChangedLines($path) + -lines.

This request doesn't describe a root problem, so we can't develop a solution to it. We haven't received any new information in more than a month. See Describing Root Problems and Contributing Feature Requests for help describing root problems and filing feature requests that the usptream can accept.

We can't reproduce this and we haven't learned any new information in more than a month, so I'm going to close it.

This report does not include reproduction steps. Bug reports must include complete, self-contained reproduction steps to be accepted by the upstream. See Providing Reproduction Steps for help.

I'm going to merge this into T10563 which is narrower but more actionable.

We don't have enough information about this problem to design a solution, and haven't received more information in more than a month. See Describing Root Problems and Contributing Feature Requests for details on how to submit an actionable feature request.

Take a look at this and see how far you can get? It might be really easy but it might also be very involved.

It's currently impossible to sort badges by rarity because they rarities are internally 'grey', 'white', 'green', etc., and there is no natural order to these. For example, MySQL has no idea what order 'indigo', 'orange' and 'yellow' should go in, except alphabetical, which is not actually the correct order.

Sounds good, let us know if you run into anything else.

For completeness, T10651 is the earlier report.

I think this should now be resolved in HEAD of master. It will likely promote to stable in about 24 hours.