summarizing patches for review (was: Gets rid of length in the docs. (issue 4965053))

[Graham Percival]

On Mon, Aug 29, 2011 at 11:32:16PM +0100, Trevor Daniels wrote:
> 
> Indeed.  Perhaps we could make a clearer distinction
> between patches that must be reviewed, like those
> which cause syntax changes, those which add new
> features and those by relative newcomers, and those
> that should simply be pushed without review, like
> bug fixes by experienced developers, minor doc changes,
> etc, with the aim of reducing further the number going to Reitveld
> and lengthening the queue.

We're already seeing developers avoiding the queue by pushing
directly.  I'm happy with the amount of that we're seeing, and we
could see a bit more -- but only if those developers really test
their stuff before pushing it directly.

Rather, I'd like to have a clearer format for the countdowns.  I'm
thinking of something like this:

SYNTAX CHANGES

issue 1234 blah

MAINTAINABILITY

issue 2345 foo
issue 3456 bar

LARGE PATCHES

issue 4567 baz
issue 5678

SHORT PATCHES

issue 6789 doc blah
issue 7890
issue 8901
issue 9012
issue 0123


the trick is coming up with the right granuality of sections; I
think that 3 or 4 sections is good.

Cheers,
- Graham