[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87edphnkg1.fsf@minerva.mail-host-address-is-not-set>
Date: Wed, 22 Mar 2023 11:34:38 +0100
From: Javier Martinez Canillas <javierm@...hat.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Matti Vaittinen <mazziesaccount@...il.com>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
Noralf Trønnes <noralf@...nnes.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Shreeya Patel <shreeya.patel@...labora.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Jonathan Cameron <jic23@...nel.org>,
devicetree@...r.kernel.org, Zhigang Shi <Zhigang.Shi@...eon.com>,
Maxime Ripard <mripard@...nel.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Paul Gazzillo <paul@...zz.com>,
Maxime Ripard <maxime@...no.tech>,
Maíra Canal <mcanal@...lia.com>,
Rob Herring <robh+dt@...nel.org>,
Dmitry Osipenko <dmitry.osipenko@...labora.com>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, kunit-dev@...glegroups.com,
Stephen Boyd <sboyd@...nel.org>, Emma Anholt <emma@...olt.net>,
Liam Beguin <liambeguin@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
Daniel Vetter <daniel@...ll.ch>,
David Gow <davidgow@...gle.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Brendan Higgins <brendan.higgins@...ux.dev>,
David Airlie <airlied@...il.com>,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v5 0/8] Support ROHM BU27034 ALS sensor
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> 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 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.
Otherwise the IIO tree will need to provide an inmutable branch for the
DRM tree to merge and so on.
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.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Powered by blists - more mailing lists