Change Details

See PHI851. `diffusion.commit.search` should accept string constants (not numeric constants) for the `statuses` constraint. See PHI847, which requests better logging from `RepositoryOperation`. A `RepositoryOperationLog` is likely reasonable. See PHI842. The query updating the repository summary table is inefficient. --- See PHI854, which would like better behavior for dashboard panels with more results than are visible. This may be easy, or may get rescheduled into T13083. See also T9903. (Kicked to T13083.) See PHI849. When a transaction includes 1,000+ inlines, the mail can take a long time to generate because it must render all the context. We should limit mail to the first, say, 100ish inlines since including inlines 101+ in mail probably isn't terribly useful. See PHI853 and D19628. It appears that JIRA has begun responding `HTTP/1.0 200` instead of `HTTP/1.0 200 OK`. This is apparently legal, just unusual. See PHI852, which is equivalent to T8573 and I expect to resolve as "the author can mark inlines done". See PHI845. Upstream `get/setInterface()` and `get/setOperation()` on `OperationType` could make more complex operations easier to write. See PHI849. An instance would benefit significantly from a fast PHP lexer for highlighting Java.

See PHI851. `diffusion.commit.search` should accept string constants (not numeric constants) for the `statuses` constraint. See PHI847, which requests better logging from `RepositoryOperation`. A `RepositoryOperationLog` is likely reasonable. --- See PHI854, which would like better behavior for dashboard panels with more results than are visible. This may be easy, or may get rescheduled into T13083. See also T9903. (Kicked to T13083.) See PHI849. When a transaction includes 1,000+ inlines, the mail can take a long time to generate because it must render all the context. We should limit mail to the first, say, 100ish inlines since including inlines 101+ in mail probably isn't terribly useful. See PHI853 and D19628. It appears that JIRA has begun responding `HTTP/1.0 200` instead of `HTTP/1.0 200 OK`. This is apparently legal, just unusual. See PHI852, which is equivalent to T8573 and I expect to resolve as "the author can mark inlines done". See PHI845. Upstream `get/setInterface()` and `get/setOperation()` on `OperationType` could make more complex operations easier to write. See PHI849. An instance would benefit significantly from a fast PHP lexer for highlighting Java. See PHI842. The query updating the repository summary table is inefficient.

See PHI851. `diffusion.commit.search` should accept string constants (not numeric constants) for the `statuses` constraint. See PHI847, which requests better logging from `RepositoryOperation`. A `RepositoryOperationLog` is likely reasonable. See PHI842. The query updating the repository summary table is inefficient. --- See PHI854, which would like better behavior for dashboard panels with more results than are visible. This may be easy, or may get rescheduled into T13083. See also T9903. (Kicked to T13083.) See PHI849. When a transaction includes 1,000+ inlines, the mail can take a long time to generate because it must render all the context. We should limit mail to the first, say, 100ish inlines since including inlines 101+ in mail probably isn't terribly useful. See PHI853 and D19628. It appears that JIRA has begun responding `HTTP/1.0 200` instead of `HTTP/1.0 200 OK`. This is apparently legal, just unusual. See PHI852, which is equivalent to T8573 and I expect to resolve as "the author can mark inlines done". See PHI845. Upstream `get/setInterface()` and `get/setOperation()` on `OperationType` could make more complex operations easier to write. See PHI849. An instance would benefit significantly from a fast PHP lexer for highlighting Java. See PHI842. The query updating the repository summary table is inefficient.