Hello Inki, On 12/04/2015 11:57 AM, Inki Dae wrote: > Hi Javier, > > 2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx>: >> Hello Inki, >> >> On 12/04/2015 06:00 AM, Inki Dae wrote: >>> Hi Javier, >>> >>> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글: >>>> Hello Inki, >>>> >>>> I found that v2 of this patch is alredy in your exynos-drm for-next branch so >>>> so I had to revert it in linux-next to apply this one to test. You shouldn't >>>> push patches that were still not reviewed (specially the ones that weren't >>>> tested like this one) to your branch that gets pulled by -next. The idea of >>>> -next is to have some test coverage but it should be as stable as possible. >>> >>> exynos-drm/for-next branch is not really for-next branch. This branch is used >> >> Well, it is a for-next branch because is pulled by -next. It is listed in: >> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees >> >> drm-exynos git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next >> >>> only for integration test. As you know, there are many exynos maintainers >>> and they have their own repository. So we would need to test the integration. >> >> Integration testing is of course very needed and linux-next is for that but >> what should be tested are the patches that are targeted to mainline. >> >>> For this, exynos-drm/for-next is merged to linux-next not Dave's tree. >>> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and >>> tested patches will be merged to exynos-drm-next. >>> >> >> In that case, exynos-drm-next is what should be pulled by linux-next, no the >> for-next branch. Linux-next is a simulation of what Torvalds would do next >> so problems are found earlier, ideally before the patches land into mainline. > > Seems I didn't comment enough. exynos-drm/for-next branch includes all > patches of exynos-drm-next > and actually, they keep same patches for most time but sometimes, I > merge additional patches only to > exynos-drm/for-next, which should be more tested with other trees > before going to Dave's tree. > Ok, but unreviewed and more importantly untested patches should not go to to exynos-drm/for-next because those will be made available in linux-next and can cause issues. Only patches that are known to be good and have been reviewed/acked should go there. > One more thing, there is other difference between exynos-drm-next and > exynos-drm/for-next. > That is all patches of exynos-drm-next are merged on top of based on > Dave's drm-next branch. > On the other hand, all of exynos-drm/for-next are merged on top of > mainline. So if exynos-drm-next It's OK if you keep a different branch because you need a different base before sending your pull request but IMHO the patches in both branches should always be the same. > is merged to linux-next then all patches will be conflicted with > Dave's tree because his branch > is also merged to linux-next. > > I'm not sure that other maintainers always keep only the for-next > branch in their repository but > in my case, I use exynos-drm/for-next branch for the test before going > to drm-next. > Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree > will also be pulled by > linux-next, which would allow exynos-drm-next to be tested altogether > again before going to mainline. > This should be a common problem for subsystems with different levels of maintainership. I'm not a subsystem maintainer so I don't know how this should be solved but I thought that git merge would take care of this when both trees are pulled by linux-next. Maybe Krzysztof can comment on this since he has to do the same for the Exynos SoC support? He maintains a for-next branch and has to send pull request to Kukjin (and sometimes may need to rebase on top of Kukjin's tree) but both trees are pulled by linux-next to test. > Thanks, > Inki Dae > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
