Messages in this thread | | | Date | Thu, 16 Apr 2009 16:46:50 -0400 | From | Theodore Tso <> | Subject | Re: [PATCH] Documentation: Add "how to write a good patch summary" to SubmittingPatches |
| |
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
| |