On Thursday, September 12, 2013 12:42:29 PM Srivatsa S. Bhat wrote: > On 09/12/2013 12:14 PM, Viresh Kumar wrote: > > On 12 September 2013 12:00, Srivatsa S. Bhat > > <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote: > >> Looking at the rate at which we are bumping into each others thoughts, I think > >> maybe we should switch from email to IRC ;-) ;-) > > > > Unbelievable, Even I thought so this morning :) > > > > One more thing that I wanted to say for some other threads.. > > Your changelogs are simply superb.. The amount of information that you put in > > them is fantastic.. > > Thank you! :-) I'm glad to hear that! > > Believe it or not, I spend almost an equal (if not more) amount of time ensuring > that I get the changelog absolutely right, compared to the time I spend actually > writing the code. The reason is that, I have been pleasantly surprised by the > power of the changelog in numerous occasions: the very act of composing a proper > changelog forces me to think *much* more clearly than when writing code. And it > often gives me the opportunity to rethink the *entire* approach/solution and not > just the implementation, since I need to explain the full context in it, not > just what the code does. And *that* exercise can reveal more complex/subtle bugs > than mere code review can ever do. That's why I put so much emphasis on writing > a perfect changelog :-) [Believe it or not, I have had times when I figured out > that my entire solution was utterly nonsensical when I began writing the changelog, > *after* reviewing and testing the code! ... and of course I had to rework the > entire patch! ;-( ] > > And to prevent myself from going overboard with writing the changelog (like making > it way too verbose or convoluted with too much detail), I have a simple mechanism/ > handy rule in place: > > The changelog should be such that, whoever reads the changelog should feel that > the time he spent reading it was totally worth it. IOW, it should not simply > regurgitate what is already obvious from the code. Instead it should provide > insights into the subtle aspects or tradeoffs relevant to the patch; in short, it > should explain the "_why_ behind the _what_" as clearly and in as few words as > possible :-) > > Well, atleast I _try_ to stick to that rule :-) Can you please prepare a patch against Documentation/SubmittingPatches with the above paragraph in it? Seriously. There are people who don't really see a reason for writing good patch changelogs. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
