On Wednesday 08 June 2016 22:15:18 Darren Hart wrote: > On Wed, Jun 08, 2016 at 09:57:26PM +0200, Pali Rohár wrote: > > On Wednesday 08 June 2016 21:48:24 Darren Hart wrote: > > > On Wed, Jun 08, 2016 at 12:03:24AM +0200, Pali Rohár wrote: > > > > On Thursday 02 June 2016 12:41:42 Michał Kępień wrote: > > > > > > Signed-off-by: Pali Rohár <pali.rohar@xxxxxxxxx> > > > > > > > > > > My guess is that Darren won't let you off without at least a > > > > > short commit message. > > > > > > > > I have no idea what else to write. I think that description is > > > > enough. > > > > > > There is always something. For example, why? See > > > Documentation/SubmittingPatches section "14) The canonical patch > > > format" for an explanation. > > > > > > "Traceability" of changes is important. If it's worth preparing > > > the patch, it's worth documenting why. > > > > In my opinion current description is enough and cover everything > > what this patch is doing. I think it is clear from my description > > what this patch is doing and so it is documented. > > > > But if it is not clear and something is missing, let me know or > > show what is wrong and how you change it... It is just my > > assumption that "Sort WMI event codes and update comments" is > > clear... > > The patch summary accurately states what it does. It does not explain > why it does it, or why it is necessary. I understand this is a > trivial change, but also understand that both maintainers and people > doing maintenance and regression analysis will appreciate > understanding the motivation and intent of the patch, in addition to > the content of the patch. > > From the maintainer perspective, whether we have 20 or 200 patches to > review, we will naturally merge the ones that require the least > effort first. This maximizes our efficiency and benefits the most > people with what time we have available. For many of us, this is our > nights and weekends (guessing that's the case for you as well). It > is in the submitter's best interest to take the time document the > why, what, and how of each patch in a way that minimizes the effort > on the part of the maintainer to decide if the patch should be > merged. It is also a matter of scale, if every patch conforms to > these guidelines, the workflow is much more efficient. > > In this case, I don't know why you decided to sort the event codes or > update the comments. I assume the comments were wrong before, but > maybe something changed. Do you care about alphabetically order or > optimizing the switch statements? Is it purely for legibility? Etc. > > If that isn't sufficient, then just do it out of self-interest, > because I will not send patches to Linus that do not provide both a > summary and a description in the commit which meet the guidelines of > section 14 referenced above. > > Thanks, I fully understand your maintainer perspective. I just though that my one line explain everything what is needed about my patch... So do you want to include reason for my patch? What about this additional description? === For better readability of keymap table, sort events by codes and also update comments for events to be more informative. === -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
