On 21 December 2015 at 14:41, Russell King - ARM Linux <li...@arm.linux.org.uk> wrote: > On Mon, Dec 21, 2015 at 02:23:17PM +0100, Ulf Hansson wrote: >> On 21 December 2015 at 13:51, Russell King - ARM Linux >> <li...@arm.linux.org.uk> wrote: >> > On Mon, Dec 21, 2015 at 01:35:36PM +0100, Ulf Hansson wrote: >> >> I decided to try to apply it for my next branch, to get some good test >> >> coverage. Although, it failed when reaching patch 8. Would you mind >> >> posting yet another new re-based version, please. >> > >> > Given that these are _fixes_ and need to be applied to -rc kernels, they >> > are based on -rc6. I don't see the point of rebasing them onto non-rc >> > kernels to test, because then you're not testing against where they >> > should be applied. >> >> I see your point, but I would rather not aim for rcs with these >> changes, unless you insist. >> >> Not because they aren't fixes, but because it's old errors. Instead we >> can "cc stable" or use the fixes tag as we are in quite late stage of >> the rc. This approach will also allow us to get a bit better test >> coverage. > > Even if we do this, we still need to get _these_ tested because _these_ > will be the ones which need to be applied to stable trees such as the > 4.4 stable series. > > What I suggest is applying them against -rc6, and then merging them > into your -next branch, and fixing the resulting conflicts. We then > have the patches ready for -rc, but which can still be tested in -next > (for what that's worth.) If people find problems, they can always > re-test these patches without all the development stuff. > > If I were to give you a set of patches suitable just for -next, then > people can only test with all the development stuff included, and we'll > have no idea whether any new problems are the result of development or > these patches.
Okay! I will publish the branch as soon as I can. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
