Messages in this thread | | | Date | Fri, 4 Dec 2015 16:07:32 -0600 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v4] livepatch: Cleanup module page permission changes |
| |
On Fri, Dec 04, 2015 at 10:57:45PM +0100, Jiri Kosina wrote: > On Fri, 4 Dec 2015, Josh Poimboeuf wrote: > > > > (1) I pull your 'modules-next' branch, apply this patch on top, and wait > > > for your merge with Linus and send merge request afterwards > > > (2) If you are okay with rebasing your tree (seems like this is > > > ocassionally happening), how about you prepare a branch that'd have > > > just b3212ec77 ("module: keep percpu symbols in module's symtab") on > > > top of some common base, I merge it, and the cross-dependency is gone > > > (3) I cherry-pick b3212ec77 ("module: keep percpu symbols in > > > module's symtab") from your tree, and apply this on top. git will > > > handle duplicate commits when Linus merges both just fine > > > (4) I sign this patch off and you merge it > > > > > > (4) seems really outside the regular process. (1) is really tricky wrt. > > > coordination of timing during the merge window. I'd prefer (2) (more > > > git-ish way of doing things, but would require you rebasing your tree) or > > > eventually (3) (git will handle this with grace). > > > > [ off-list ] > > :-) > > > Quick question. Just curious, because I'm new at this... > > > > My impression was that #1 was standard operating procedure. Merge a > > (non-rebasable) modules branch into livepatch, and then make sure to > > submit the livepatch pull request after Rusty sends his, with a note in > > the mail to Linus stating the dependency. That seems pretty > > straightforward to me. Or am I missing something? > > It's one of the options, yes. The only drawback is that it introduces, in > addition to the actual code cross-dependency, also maintainer timing > cross-dependency, and it might easily go wrong during merge window. But > I've done this quite a few times already, and it was rather smooth. > > What I actually prefer doing in this case is have a common merge base as a > separate branch that gets merged to both trees, and then it's not really > important who merges first. But that'd require in-advance planning and > structuring Rusty's tree for that, and that's probably not worth the > hassle for these few patches.
Ah, got it. That does sound better, assuming there's some advance planning. Thanks for educating me :-)
-- Josh
| |