RFC tips-for-maintainers.txt (was Re: [GIT PULL] platform-drivers-x86 for 4.6-3)

[Michael Ellerman]

On Wed, 2016-04-27 at 09:57 -0700, Darren Hart wrote:
> On Wed, Apr 27, 2016 at 09:08:01AM -0700, Linus Torvalds wrote:
> > On Tue, Apr 26, 2016 at 10:02 PM, Darren Hart <dvhart@xxxxxxxxxxxxx> wrote:
> > >
> > > Found myself not wanting to send a one patch pull request, but not wanting to
> > > wait until RC6 and possibly miss 4.6.
> > >
> > > Do you have a preference during the RC cycle in terms of balance between patch
> > > count and frequency for a small subsystem like platform-driver-x86?
> >
> > Once a week like this is fine, even if it's just a single trivial
> > one-liner change.
...

> Very helpful, thank you Linus. I believe I just inherited a TODO to find the
> right spot in the documentation to record this.

Actually I've been meaning to do that for ages, and I have a few more collected
in my notes.

How do these look?


  Git pulls should start "[GIT PULL]":

      http://lkml.kernel.org/r/CA+55aFxURVwV4NZcPsVzQ-Ui9Nmn2vdXVw==S5RKhXC1y4b8og@xxxxxxxxxxxxxx

       just for your information: this pull request doesn't show up with my
      normal merge-window search pattern of "git pull", because you never
      actually say "pull" anywhere.

      Please use a subject with "[GIT PULL]" prefix (preferred), or just
      change the body of the email to have a "please pull" in it or
      something.  I get too much email, and particularly during the merge
      window it really helps if I can keep my pull emails separate from
      other stuff by just having them match a simple pattern.


  Linus generally likes to see merge conflicts himself, for subtle conflicts
  you can provide a separate tree with the result of your merge:

      http://lkml.kernel.org/r/CA+55aFwM2e9sTVtYjrnPjh5RsZafBXbJ5FFYkYi730ojOn+8-w@xxxxxxxxxxxxxx

      On Sat, Sep 5, 2015 at 2:37 AM, Neil Brown <neil@xxxxxxxxxx> wrote:
      >
      > Please pull these updates.  I've already merged with the 'block' tree
      > to resolve a few simple conflicts.

      So for the future, I actually prefer to see and handle the conflicts myself.

      I really just prefer knowing what's going on, and merge conflicts are
      an indication of cross-maintainer issues which are *exactly* the kinds
      of things I want to be aware of.

      However, in this case I was "ok, I've already done several other merge
      resolutions with the wbole damn bio_endio error handling changes", so
      I felt I was aware enough about how that ended up being a
      cross-subsystem conflict, and just took your pre-merged version.

      If you feel that the conflicts are particularly subtle, or just
      generally worry about the merge, or just because you want to do some
      merge-testing, what some people end up doing is to send me their
      unmerged branch, and then send me a separate ".. and here's the merge
      I did". I'll then do the merge myself anyway, but then after doing the
      merge I'll switch to a temporary testing branch and re-do the  merge
      with the pre-merged state just to verify. Generally the end result is
      identical, but when it isn't, that's actually usually interesting
      (sometimes it's just a ordering difference, but sometimes it's a merge
      error - and so far I think most merge errors have come from
      sub-maintainers, for the simple reason that they generally aren't as
      used to merging as I am - so even if they know the code better, I
      sometimes catch merge gotcha's better).

  Don't rebase your tree between linux-next and requesting a pull unless you
  absolutely must:

      http://lkml.kernel.org/r/CA+55aFyrep8hMApzYA4DyFgEoHc8o8KATTV=Jqf6-FgtLsqFOQ@xxxxxxxxxxxxxx

      Just stop [rebasing]. I'll handle the merge issues. If there are
      complicated merge problems that you really worry about, what you can do
      is

       (a) make a test-merge just to check

       (b) do NOT send me that test-merge

       (c) as part of the pull request, tell me that "there's a conflict
      because xyz, and this is how we think it should be handled".

      ...

      There are valid reasons to rebase, but those are along the line of "we
      messed up catastrophically, and we _have_ to clean up the history".

      A simple merge conflict due to a trivial duplicated commit is not a reason.

  Linus likes signed tags with a short blurb:

      http://lkml.kernel.org/r/CA+55aFwa9b5=aYKXNKfCaQN27PFY8GChuhCK+pkrqCfGn6FpKQ@xxxxxxxxxxxxxx

      .. the above is a tag, but it's not signed, nor even annotated. So it
      has no message about what the fixes are in it, it's just the plain
      SHA1 id.

      Now, I don't really require signed tags from kernel.org, but it would
      still be nice. And I *do* want a little blurb about the fixes, even if
      it doesn't have to be all that exhaustive. Putting that in the tag is
      convenient, but I'm ok with it being just in the email message too,
      like you usually do.

  Linus really wants signed tags when pulling from non-kernel.org, even if your
  key is not (yet) signed by other kernel devs:

      http://lkml.kernel.org/r/CA+55aFzXUoh6ktJ+wWmwdg6ERjHJWbvrKQ5CoRCy-Sw620Ex+g@xxxxxxxxxxxxxx

      I really want to see signed tags when pulling from non-kernel.org places.

      Even if you don't have signatures I can check on your keys, I want to
      see your key used for signing anyway, so that when your next pull
      request comes in I see that it's the same key (and hopefully you
      _will_ have signatures on your key eventually).

      And: CA+55aFw0f9bojYF4_NGXE7ZgPn4oOoWELBnyJRVRjfX3cuJBag@xxxxxxxxxxxxxx

  Sending a weekly pull request during the rc period is a good pattern, but
  more frequent is fine as long as there is a reason:

      http://lkml.kernel.org/r/CA+55aFwtirweH2pwo9T5=CtrHeEYtLyYtCZXmOOefo3e24tFdA@xxxxxxxxxxxxxx

      I don't mind small pull requests at all, and I don't see "just one
      tiny commit" as being a bad thing. Quite the reverse. Those pull
      requests are easy, and it just makes me feel "good, that subsystem is
      calm and quiet, but not because the maintainer is not responding to
      people".

      In fact, getting small pull requests more often that once a week is
      also perfectly fine, although at that point there should be some
      _reason_ for it. But there are lots of valid reasons ("this is urgent
      because X", but also obviously things like "I maintain five different
      topic branches, this fourth pull request this week is for that other
      topic").

      The thing to avoid is a pattern of lots of pointless small pull
      requests, and in particular "oh, we found a problem in the last
      hurried pull requests, so here's _another_ half-arsed hurried pull
      request to fix that". At that point, I'd much rather just see the
      maintainer keep the commits in his tree for longer, and test them
      better, and just let them cook a bit more. So I _will_ complain if I
      notice that there's commits that are very recent and they look dodgy.

  And: http://lkml.kernel.org/r/CA+55aFyv0i7x5ZcHK6VnUdkbRtzQPPUxYUm_s1DMoPBqf0n=Mg@xxxxxxxxxxxxxx

      One pattern that is _very_ clear here is how the pull requests I get
      are bunched up at the end of the week. More than half of all my pulls
      were done Friday and particularly Saturday. I'm not complaining, I
      think it's just a sign of how there weren't any particularly urgent
      things going on this week, and so people send in their pull requests
      at the end of the work-week and/or just knowing that the rc is coming
      up.

cheers