On Wed, Mar 22, 2023 at 12:59:33PM +0200, Matti Vaittinen wrote: > On 3/22/23 12:34, Javier Martinez Canillas wrote: > > > On Wed, Mar 22, 2023 at 11:05:23AM +0200, Matti Vaittinen wrote: ... > > > > - copy code from DRM test helper instead of moving it to simplify > > > > merging > > > > > > 1) Why do you think this is a problem? > > > 2) How would we avoid spreading more copies of the same code in the future? > > > > > > > > > 1) Merge conflicts is not a bad thing. It shows that people tested their code > > > in isolation and stabilized it before submitting to the upper maintainer. > > > > > > https://yarchive.net/comp/linux/git_merges_from_upstream.html > > > > > > 2) Spreading the same code when we _know_ this, should be very well justified. > > > Merge conflict is an administrative point, and not a technical obstacle to > > > avoid. > > I definitely agree. This is also why I did the renaming and not copying in > the first version. In this version I did still add the subsequent patch 2/8 > - which drops the duplicates from DRM tree. > > > I believe this was suggested by Maxime and the rationale is that by just > > copying the helpers for now, that would make it easier to land instead of > > requiring coordination between different subystems. > > This is correct. > > > Otherwise the IIO tree will need to provide an inmutable branch for the > > DRM tree to merge and so on. > > Or, if we carry the patch 1/8 via self-test tree, then we get even more > players here. > > Still, I am not opposing immutable branch because that would allow fast > applying of the patch 2/8 as well. Longer that is delayed, more likely we > will see more users of the DRM helpers and harder it gets to remove the > duplicates later. > > > I agree with Maxime that a little bit of duplication (that can be cleaned > > up by each subsystem at their own pace) is the path of least resistance. > > I'd say this depends. It probably is the path of least resistance for people > maintaining the trees. It can also be the path of least resistance in > general - but it depends on if there will be no new users for those DRM > helpers while waiting the new APIs being merged in DRM tree. More users we > see in DRM, more effort the clean-up requires. > > I have no strong opinion on this specific case. I'd just be happy to see the > IIO tests getting in preferably sooner than later - although 'soon' and > 'late' does also depend on other factors besides these helpers... Since I'm not a maintainer of either, and one of them requires something, I can't oppose. -- With Best Regards, Andy Shevchenko