Change Details

See PHI356, which has some reasonable suggestions for minor improvements to the filetree view. See PHI595, which also has a reasonable suggestion for the filetree view ("respect deuteranopia mode"). See PHI431. See PHI426. Multiple installs would like more sophisticated reviewer behavior. Current requests are roughly: - "Accept this diff on behalf of packages I have authority for, but revert those packages to blocking reviewers when the revision is updated." - "Add me as a blocking reviewer, but only for a short period of time." I suspect these lead to T731 and T10574, practically. See PHI523. When a revision auto-updates with a commit, reviewers become "Accepted Prior Diff". We should probably retain their status relative to the last human diff, ignoring the auto-update. See PHI598. Very large revisions still build `$packageChangesetMap` and `$pathPackageMap`, but these are mostly not useful. The path map is unused (since we don't render a ToC) and the changeset map is used only to render "(Owns no Paths)" in Reviewers, which we can reasonably just degrade out of without a significant functional impact. --- //Largely Resolved?// See PHI483. There's currently a bad interaction between builds completing and drafts unpublishing, described in greater detail in T13108. See PHI283. When a draft revision is abandoned, it should retain its "draftness" in some sense and not send email. With the above change, revisions should also probably be able to demote into a "Changes Planned + But, Still a Draft" state. See PHI230, where I plan to explore the `[----++ ]` element described in D16322 and see how it works. See PHI485 and PHI489. An install would like better behavior from Differential when reviewing revisions which change 5,000+ files and have 1,000+ reviewers. See also T8612.

See PHI356, which has some reasonable suggestions for minor improvements to the filetree view. See PHI595, which also has a reasonable suggestion for the filetree view ("respect deuteranopia mode"). See PHI431. See PHI426. Multiple installs would like more sophisticated reviewer behavior. Current requests are roughly: - "Accept this diff on behalf of packages I have authority for, but revert those packages to blocking reviewers when the revision is updated." - "Add me as a blocking reviewer, but only for a short period of time." I suspect these lead to T731 and T10574, practically. See PHI523. When a revision auto-updates with a commit, reviewers become "Accepted Prior Diff". We should probably retain their status relative to the last human diff, ignoring the auto-update. See PHI598. Very large revisions still build `$packageChangesetMap` and `$pathPackageMap`, but these are mostly not useful. The path map is unused (since we don't render a ToC) and the changeset map is used only to render "(Owns no Paths)" in Reviewers, which we can reasonably just degrade out of without a significant functional impact. The output of `arc diff` when a revision affects a very large number of files is not especially useful, since it ends with a list of every file which can leave the actual URI to the revision lost many pages back in your scroll buffer. Better would probably be the first 100 files and then "And 7389 more files", or moving the URI to the bottom. --- //Largely Resolved?// See PHI483. There's currently a bad interaction between builds completing and drafts unpublishing, described in greater detail in T13108. See PHI283. When a draft revision is abandoned, it should retain its "draftness" in some sense and not send email. With the above change, revisions should also probably be able to demote into a "Changes Planned + But, Still a Draft" state. See PHI230, where I plan to explore the `[----++ ]` element described in D16322 and see how it works. See PHI485 and PHI489. An install would like better behavior from Differential when reviewing revisions which change 5,000+ files and have 1,000+ reviewers. See also T8612.

See PHI356, which has some reasonable suggestions for minor improvements to the filetree view. See PHI595, which also has a reasonable suggestion for the filetree view ("respect deuteranopia mode"). See PHI431. See PHI426. Multiple installs would like more sophisticated reviewer behavior. Current requests are roughly: - "Accept this diff on behalf of packages I have authority for, but revert those packages to blocking reviewers when the revision is updated." - "Add me as a blocking reviewer, but only for a short period of time." I suspect these lead to T731 and T10574, practically. See PHI523. When a revision auto-updates with a commit, reviewers become "Accepted Prior Diff". We should probably retain their status relative to the last human diff, ignoring the auto-update. See PHI598. Very large revisions still build `$packageChangesetMap` and `$pathPackageMap`, but these are mostly not useful. The path map is unused (since we don't render a ToC) and the changeset map is used only to render "(Owns no Paths)" in Reviewers, which we can reasonably just degrade out of without a significant functional impact. The output of `arc diff` when a revision affects a very large number of files is not especially useful, since it ends with a list of every file which can leave the actual URI to the revision lost many pages back in your scroll buffer. Better would probably be the first 100 files and then "And 7389 more files", or moving the URI to the bottom. --- //Largely Resolved?// See PHI483. There's currently a bad interaction between builds completing and drafts unpublishing, described in greater detail in T13108. See PHI283. When a draft revision is abandoned, it should retain its "draftness" in some sense and not send email. With the above change, revisions should also probably be able to demote into a "Changes Planned + But, Still a Draft" state. See PHI230, where I plan to explore the `[----++ ]` element described in D16322 and see how it works. See PHI485 and PHI489. An install would like better behavior from Differential when reviewing revisions which change 5,000+ files and have 1,000+ reviewers. See also T8612.