[Re: linux-next: please add queue for removal of __cpuinit and friends.] On 26/06/2013 (Wed 11:22) Stephen Rothwell wrote: > Hi Paul, > > On Tue, 25 Jun 2013 11:27:02 -0400 Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx> wrote: > > > > Would you please add the patch queue below to linux-next for > > the remainder of this week and the two weeks of the merge window? > > Maybe. I will see how much pain it causes me. > > > It is the patch queue for removal of __cpuinit ; a git repository > > of patches with a series file that can be browsed here: > > > > http://git.kernel.org/cgit/linux/kernel/git/paulg/cpuinit-delete.git > > > > or cloned directly from here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/cpuinit-delete.git > > > > and the deletion and merge strategy was described here previously: > > > > https://lkml.org/lkml/2013/6/20/513 > > Yeah, I should have responded to that. Given that the meat of this > series is the first 2 patches (the rest is merely cleaning up the uses of > the now mulled out macros, right) I think it would have been better (i.e. > easier for me :-)) if you had a git tree based on v3.10-rc<something> and > then did a sweep after v3.11-rc1 was out to clean up the rest. If you'd still rather go that way, then there is such a two patch branch at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git cpuinit-delete Those are the ones that will be (hopefully) added early on in the merge window anyway. Note that you'll get a conflict on vmlinux.lds because the __devinit delete is in Greg's drivers-next tree and not yet mainline. > > I do not expect any significant changes to the repository going forward. > > Perhaps adding a couple more "Acked-by:" tags, and dropping a couple > > patches for when maintainers request to carry them locally. So I hope > > it should not be a big burden. And it is a one-shot tree as well. > > The problem is that it is based on shifting sands i.e. linux-next. This > means that I will have to rebase it each day onto the new linux-next just > before I release it. I already do this with Andrew's tree and that is a > bit of a pain already. Understood. Feel free to take the two patch approach if it is too much hassle. If you do, I will continue to track applicabiliy of the "sweep" patches locally on your daily linux-next as I had been. > It also means (given that some linus-next included trees do not actually > get merged for -rc1), that some of these patches may never apply cleanly > to Linus' tree. Yep, but at the same time, linux-next is about 8,000 commits closer to what the "sweep" patches will be landing on, so I think it was still the right baseline for me to be doing this work against while we wait for the merge window. Thanks for giving the whole series a spin for at least one next tree, as it probably helped to ensure people are more aware the change is coming. Paul. -- > > I will try it today and see how we go. I assume that the current set of > patches is based on next-20130625? > > -- > Cheers, > Stephen Rothwell sfr@xxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
