Re: [PATCH] Documentation: Add "how to write a good patch summary" to SubmittingPatches

[Theodore Tso <tytso@mit.edu>]

On Thu, Apr 16, 2009 at 10:12:55PM +0200, Ingo Molnar wrote:
> as a bug triager i can, within 1 minute, sort all the commits by 
> risk:
> 
> Low risk cleanups:
>     ...
> Runtime crash fixes:
>     ...
> Robustness enhancements:
>     ...
> Low-risk features:
>     ...
> High-risk features:
>     ...

Sure, but if that's the goal, maybe instead we should have some
keywords that we tag onto one-line summary, i.e.

ext4 <LR,cleanup>: 
ext4 <MR,feature>: 
ext4 <HR,crashfix>:
ext4 <MR,robustness>:
ext4 <MR,errorcheck>:

That way it would become even *easier* for someone sorting through the
output of "git log --oneline".  (Note that sometimes a crash fix can
be either high, medium, and low risk --- and even there we will have
some differences between maintainers; but I think three categories is
sustainable.  At least it gives some differentiation between commits
within one subsystem.)

> And that's just 18 commits. We have 10,000 commits in every kerenel 
> cycle, and more than 1000 commits of that go via the trees hpa and 
> me is maintaining. It's 2-3 orders of a magnitude difference.

Right, but separating the Imact line from the one-line summary, and
not having an even *more* rigid and compact set of tags means we
should be able to make things even easier.

My main complaint with the Impact line is that given the stated goals,
it's too freeform, and it's separated from the patch summary.  The
rest of the body of the commit is free-form.  So if the goal is to
make it easy to sort through 10,000 commits, let's take even further.

Best regards,

					- Ted