Cleans up colors, removes commit hash and links the text instead. Also unsure how valuable "lint" column is here, but left it. I'd maybe like to understand that workflow since it just seems like clutter overall. Also Fixes T12905
Details
- Reviewers
epriestley - Maniphest Tasks
- T12905: Diffusion browsing is broken for SVN
- Commits
- rP39e5da7ea700: Simplify Diffusion Browse Table
Review Phabricator, hg, and a few other test repositories locally. Holler if anything here seems bad, but this feels easier to read and use to me.
Diff Detail
- Repository
- rP Phabricator
- Branch
- diffusion-latest-commit (branched from master)
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 17646 Build 23689: Run Core Tests Build 23688: arc lint + arc unit
Event Timeline
"Lint" and "Coverage" are pretty niche and could reasonably be alternatives for this view after T9524. They're basically just useful when you're actively trying to hunt down lint issues or improve coverage, and don't need to be available all the time. They also don't really work particularly well today since the implementation was sort of half-good to start with and has been left behind for the last few iterations.
Yeah lint... unsure. In some respects I could see it being better served in Owners. Like, I "own" phui, so I may want to keep my stuff lint free.
The use cases it's sort of targeted at are something like this:
- I want to fix every outstanding lint issue of type X in the codebase, so we can do something (finish a migration, delete old code, whatever).
- Or, I just added lint warning X and want to fix the existing backlog of technical debt of existing situations it catches.
- Or, I periodically want to fix everything that has slipped through in a whole repository or a section of a repository.
- Or, overall lint policy has changed (maybe after a meta-change like T1549, maybe just after changes to .arclint configuration) and I want to make changes in response.
In these cases, a browse view with lint annotations can help me:
- Figure out the total size of the job (Can I do it in one change? Several changes? Only with help?). Knowing this ahead of time will help me figure out how big a project it is and make a decision about how to move forward (I might: just do it myself or file a task and get help with pieces, invest time in writing scripts to help with the change or not judge that to be worth it, do it in multiple passes so the old version keeps working or in a single pass, and do it immediately or put it off).
- Click around to get a better sense of where the problems are (are they all spread out, or are they mostly concentrated in a few areas of the codebase?). Sometimes this can change action, like if everything is in an application we're about to delete (as a trivial example). In other cases it can help reduce the problem space or help break it up into useful chunks (e.g., fix outliers by hand, then we just need to fix a bunch of stuff in applications X and Y, so this is really two areas of focus).
- Monitor progress for long-running changes. If I end up filing a task and getting help, I could check in every few weeks and compare how things are doing to the last time I checked in. If I find things are, say, getting worse, I might try to prevent whatever's going wrong from continuing (e.g., by adjusting the current state of lint). The browse view isn't perfect for this since I don't expect it to actually be able to compare "last week vs this week" necessarily after T9524, but when I checked in I could just manually write a status comment on the task ("This looks like it's moving along steadily, we have X left.") and compare to that, which is reasonable.
All of this stuff is just nice to have, but it's specific tooling support for workflows with a relatively well-defined goal. But the current UI doesn't serve these goals especially well and you don't need this stuff unless you're pursuing one of these goals, so I don't think we're losing much by removing it from the default view.