Message ID | 20161013140746.GA14174@localhost |
---|---|
State | Not Applicable |
Headers | show |
On Thu, Oct 13, 2016 at 7:07 AM, Bjorn Helgaas <helgaas@kernel.org> wrote: > > Here are some more changes I'd like to have in v4.9. There's one small > Tegra bug fix in the PHY poweroff path, which is only used in failure > paths. The rest is all strictly cleanup that should make host bridge > drivers more readable, but shouldn't actually change any behavior. Ugh: > PCI changes for the v4.9 merge window: > > Altera host bridge driver > Add local struct device pointers (Bjorn Helgaas) Your "summary" is actually less legible than the shortlog, and looks entirely auto-generated. That's against the whole point of having a summary for a pull request. Please tell me what changed, don't auto-generate pointless unreadable crud. Ok? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 13, 2016 at 4:48 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Ugh: > > Your "summary" is actually less legible than the shortlog, and looks > entirely auto-generated. > > That's against the whole point of having a summary for a pull request. > > Please tell me what changed, don't auto-generate pointless unreadable crud. Ok? I wrote some kind of summary based on actually (hopefully) intelligent culling of relevant information instead of just bunching up together automated data. It may not be complete, but it's the kind of "what does this merge actually _merge_" information that is useful. Please do something like this in the future rather than the automated illegible mush: "Summary: - use local struct device pointers in many host bridge drivers for clarity - remove unused platform data - use generic DesignWare accessors - misc cleanups: remove redundant structure entries and re-order structure members to put comon generic fields first etc" See? Humans can read that and get an idea of what is going on. It would be even better if it had a few more lines about why those things matter, but as is, it's much better than that that tag contained. But the reason I want the maintainer to write this is that I'm lazy. No, wait, it's really because you are supposed to know the high-level detail and be able to really notice what is relevant. I just went by looking for patterns in the shortlog, doing silly things like git shortlog ..FETCH_HEAD --no-merges | cut -d: -f3- | sort | uniq -c | sort -n to get a feel for what you had done. But because I don't know the code, maybe I missed some really important change, or mis-characterized it somehow, or whatever. Which is why I want the pull requests to contain the kind of relevant information on what the hell is going on. Not just a "this is all that happened" munged shortlog in a slightly different format. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 13, 2016 at 05:21:40PM -0700, Linus Torvalds wrote: > On Thu, Oct 13, 2016 at 4:48 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > Ugh: > > > > Your "summary" is actually less legible than the shortlog, and looks > > entirely auto-generated. > > > > That's against the whole point of having a summary for a pull request. > > > > Please tell me what changed, don't auto-generate pointless unreadable crud. Ok? > > I wrote some kind of summary based on actually (hopefully) intelligent > culling of relevant information instead of just bunching up together > automated data. > > It may not be complete, but it's the kind of "what does this merge > actually _merge_" information that is useful. Please do something like > this in the future rather than the automated illegible mush: > > "Summary: > > - use local struct device pointers in many host bridge drivers for > clarity > > - remove unused platform data > > - use generic DesignWare accessors > > - misc cleanups: remove redundant structure entries and re-order > structure members to put comon generic fields first etc" That's accurate, thank you, and sorry for not providing it myself. I guess I've always been a little confused on what to put in the email vs. what should be in the tag message itself. I'm glad you pointed this out because it's just dawning on me that the tag message does not become part of your tree when you pull the tag, while the summary from the email pull request normally does. I've been focusing on the tag message, not the email summary, which was completely backwards. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 14, 2016 at 6:25 AM, Bjorn Helgaas <helgaas@kernel.org> wrote: > > I guess I've always been a little confused on what to put in the email > vs. what should be in the tag message itself. So I actually end up using either or *both* for my merge messages. A lot of people put a "short and concise bulleted summary" in their tag message, and then put more of a free-form "wall of text" explanation in the email. Other people just put both in the tag, and let "git request-pull" take the tag-message as-is for the email. Yet other people don't really use the tag at all (Bottomley, for example, tends to have just something like "scsi-20161014" in his tag) and then the explanation and summary in the email. All of those options are _fine_. I don't really mind much one way or the other. But what I don't want in *either* the tag *or* the email message is just some automated list of all the commits. (Except for the shortlog itself, I mean. I obviously want *that* automated list of commits in the email, together with the expected diffstat) I actually think that from a first approximation, James Bottomley's approach is a good starting point. Why? Because if you think of the email as something that you send to me to explain why I should pull and what I get, your email summary text is likely all I really want. The people who put the message in the tag have often started out that way, and then they get to the point where they just automate the pull request thing by just writing a message _once_ (for the tag), and have it automatically show up in the email body. So I don't actually care much where the text is. I do want the email itself to have the summary explanation (so that I can see what you are talking about _before_ I even fetch the tag), but it's ok if the tag has some extra summary detail in it, or if the tag has just the same summary as the email, or if the tag has basically nothing at all and ends up being used only for signing purposes. What I *do* care about is that the explanation is an *explanation*. For *humans*. It's an explanation for me ("Why should I pull?") but it's also an explanation for the future ("What goes into the merge message?"). Btw, many people explain things like expected merge conflicts etc, and those I usually don't put in the merge message simply because they no longer make sense after the merge is already done. So the "for me" and "for the merge message" is not always the exact same thing, but to a close approximation the two are often very similar. And I do end up always editing the merge message. So in no case do I blindly take whatever you send me. Sometimes the editing is very minimal, sometimes I end up having to do major editing for typos or layout or something. But there is no automated "turn the email and tag into a merge message". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html