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
Why do you think this is a problem?
How would we avoid spreading more copies of the same code in the future?
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
- 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.