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

[Trevor Daniels]

Graham, you wrote Wednesday, August 31, 2011 6:11 AM


> On Tue, Aug 30, 2011 at 11:25:27PM +0100, Trevor Daniels wrote:
> > Graham, you wrote Tuesday, August 30, 2011 2:43 AM
> >
> > >LARGE PATCHES
> > >
> > >SHORT PATCHES
> >
> > I think just CODE PATCHES for these.  It's
> > hard to think of a meaningful difference.
> > Number of affected files, number of changed
> > lines, lines of changes C++ and/or scm?
>
> Combination of all the above?  I don't want to have any criteria
> that would take a non-programmer more than 10 seconds to decide
> which a patch falls into.  But I'm fine with just CODE PATCHES.

Yes, that's what I meant.  Although I have a
preference now for the following ...

> > Or maybe split into ENHANCEMENTS and BUG FIXES.
> > Enhancements generally will require more
> > thought and discussion.
>
> Will it be obvious to a non-programmer (i.e the patch meister) to
> decide which is which?  

If the patch is related to an issue then the
issue Type should indicate whether it is an
enhancement or not.  I suggest Type-enhancement
and Type-other and any patches which don't have
a related issue should be listed as ENHANCEMENTS.
Anything else as BUG FIXES.  I think Colin
already inspects the related issue, so that
shouldn't be much more work.

Trevor