On Wed, Jan 31, 2018 at 1:04 PM, Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote:
>
> On the topic of back merges, can you give some guidance?
>
> With some success, we've encouraged all the driver vendors to test -rc
> kernels and test our RDMA for-next internally during the entire -rc
> cycle. Most of the testers are taking RDMA for-next and merging it
> with latest -rcX then testing the result.
>
> Due to the conflict above our tree was left with complicated merge
> conflicts for about 3-4 weeks, and some of the testers have had pain
> due to this.
>
> Would back merging -rcX ealier, with a similar but better merge
> commit, be an acceptable practice?
I'd hesitate to say "sure" in general.
For pure testing of temporary kernels that aren't actually in any way
upstream anyway, is there any reason why you can't just have a
separate kernel with the merges in place, but not make them part of
your development tree? Think of how "linux-next" works on a big scale:
there's tons of random merges there exactly so that people can test
the end result, but those merges are understood to be temporary and
not part of the development trees themselves.
So back-merges are not necessarily evil, and they _can_ be done well.
But I don't actually see your case as being a reason for them in
general.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
