On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote: > > Linus, do you have any advice on how best to handle sharing mm > > patches? The hmm.git was mildly painful as it sits between quilt on > > the -mm side and what seems like 'a world of interesting git things' > > on the DRM side (but maybe I just don't know enough about DRM). > > I think the approach in this merge window worked fairly well: > - refactor/rework core mm stuff in (h)mm.git > - handle all the gpu stuff in drm.git > - make the clashes workable through some clever prep patches like > we've done this time around Okay, as long as we agree. I think part of the challenge with hmm.git was setting some expectation for managing conflicts - there is some happy middle ground between none & scary we need to navigate to make this work. > I think Linus wants to be able to look through core mm stuff quite > closely, so not a good idea if we deeply intertwin it with one of the > biggest subsystems there is. There is definately a bunch of stuff that is under the mm/ directory but is not quite 'core mm' - it would be good if we could rely on mailing list review of that part and use a topic workflow to manage things. This was/is more or less my plan with hmm.git Otherwise yes, as much as reasonable we should avoid topic merges between the trees. However, I again see conflict risk coming this cycle .. > And I don't think there will be a real conflict like this every > merge window, this should be the exception. Worst case we have to > stage some work 1 release cycle apart, i.e. merge mm stuff first, > then drm 3 months later. I really dislike this idea. Not being able to provide users for core APIs is a huge process/review problem. Worse it tends to create a 'ladder' where in-flight changes to drivers (to implement the new core) now block any changes to the core APIs on alternating cycles. So 'the big pitcture' starts to fall a part if we can't co-ordinate cross tree changes in some way. .. and honestly, splitting a review process across a 9 week gap is one of the best ways I've seen to get a poor quality review :( I'm pretty familiar with this problem, we had it in spades between RDMA and netdev for a long time, and it is finally fully resolved now through a careful use of topic branches and merges. For example, next week I'll queue CH's patches that shift the last batch of hmm 'conflict management' shims into nouveau, and tries to fix them: https://patchwork.kernel.org/project/linux-mm/list/?series=141835 This is something uncontroversial that really should go into the DRM world as a topic so it doesn't interfere with ongoing nouveau dev. But I want to keep the hmm.c/.h bits in the hmm.git to avoid conflicts. So, I'll put it on a topic and send you two a note next week to decide if you want to merge it or not. I'm really unclear how nouveau's and AMD's patchflow works.. Thanks. Jason _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
