[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers
hannes at cmpxchg.org
Tue Jun 19 13:43:14 UTC 2012
On Tue, Jun 19, 2012 at 08:59:28AM -0400, Steven Rostedt wrote:
> On Mon, 2012-06-18 at 13:53 -0700, H. Peter Anvin wrote:
> > On 06/18/2012 01:50 PM, Jiri Kosina wrote:
> > >
> > > Well, sometimes it's not immediately obvious from the changelog what kind
> > > of bug is actually being fixed (and yes, I know that for some of the
> > > security fixes this is on purpose :-) ).
> > >
> > > So, speaking with my SLES kernel maintainer hat on, having some
> > > 'categorization' of the bug that is being fixed by a particular -stable
> > > patch, would be extremely helpful.
> > >
> > This seems to be going down the rathole that we tried to address with
> > the "Impact:" notes in -tip. It didn't work :(
> I think the problem with this was that we required that tag for all
> commits. We started getting redundancy, especially when the subject
> basically stated the impact as well.
> Then we also had:
> Impact: clean up
...in patches that were actually bug fixes.
> For things like code clean ups and such. It did become a bit of a
> burden, and I thought it made the change log a bit ugly. I still cringe
> when I'm going through old commits and see them.
> But I do believe that the idea was valid, just the way we implemented it
> was flawed. Adding a tag or something to what is fixed may be useful.
> And only add it for things that actually fix something. Or perhaps
> require it for any commit that has a stable tag on it. If you Cc,
> stable, you should have something like:
> Cc: stable at vger.kernel.org
> Fixes: Crash on board Foo
Can we instead ask people to describe the user-visible change in the
first paragraph of the changelog? I'm all for agreeing on a more
structured changelog format, but not those taglines again ;-)
Making people write things out is good _because_ not everybody writes
the same high quality changelogs. We want bad changelogs to stand out
and not hide behind a tagline that is easier to get right formally.
It allows you to identify patches that need a harder look to make out
their actual impact, instead of suggesting a single tagline would be
an accurate summary of the patch.
Being precise is hard. If you limit the amount of words, it will only
result in incomplete descriptions. If you allow a dumb format that is
easy to get right, it's harder for readers/maintainers to
identify/push back on the sore thumbs.
Your example: why not start the first paragraph of the changelog with
"Fix crash on board Foo, where..."
instead and allow people to be detailled?
More information about the Ksummit-2012-discuss