On 3/22/23 12:34, Javier Martinez Canillas wrote:
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> writes:
Hello Andy,
On Wed, Mar 22, 2023 at 11:05:23AM +0200, Matti Vaittinen wrote:
Revision history:
v4 => v5: Mostly fixes to review comments from Andy and Jonathan.
- more accurate change-log in individual patches
- 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...
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
