Messages in this thread | | | Date | Wed, 9 Mar 2016 14:27:30 -0000 | Subject | Re: [PATCH 2/7] Docs: Bring SubmittingPatches more into the git era | From | "David Woodhouse" <> |
| |
> I wrote that text that way because certain high-profile maintainers have > said exactly that sort of thing: > > You can send me patches, but for me to pull a git patch from you, > I need to know that you know what you're doing, and I need to be > able to trust things *without* then having to go and check every > individual change by hand. > > -- Mr. T. https://lwn.net/Articles/224135/ > > ...and because, in truth, few maintainers do take pull requests. There > *is* some value in having the code out on the lists in the clear, it > raises the chances of somebody *else* looking it over slightly. There is > a reason why review is done on the lists, not directly from repositories. > > Allowing the maintainer to attach tags certainly seems like another valid > reason to defer setting patches into git-implemented stone. But I don't > see it as the only one. > > We could, I suppose, run a poll to ask maintainers why they are reluctant > to take pull requests. But the end result is kind of the same as far as > readers of SubmittingPatches are concerned - they need to send their > patches via email.
You are quite right that it has the same effect in practice, for Linux. The problem was that your words were being taken out of context in a situation where email review *was* always going to be required anyway, but I'm trying to get them to allow pull requests instead of always losing history by *forcing* a rebase onto the current HEAD.
Which is a model we use often too -- post for review and feedback, but submit a pull request with the *actual* set of commits that were tested, on the base they were developed against. Instead of submitting *only* patches and running the risk that what gets committed to today's tree has *never* actually worked correctly, when we look back at the inaccurate history.
-- dwmw2
| |