Message-ID: <df98177a-58e6-b5a3-d6b6-307625ba17b5@users.sourceforge.net>
Date:   Wed, 7 Sep 2016 08:40:50 +0200
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     linux-acpi@...r.kernel.org, Hans de Goede <hdegoede@...hat.com>,
        Len Brown <lenb@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Zhang Rui <rui.zhang@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org,
        Julia Lawall <julia.lawall@...6.fr>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: ACPI-video: Fine-tuning for several function implementations

> Your patches happen to modify code maintained by me.  From my
> perspective the value of the changes made by them is marginal.

Thanks for another bit of interesting information.


> Nevertheless, I might take them if you made my life somewhat easier,

I am also looking for further approaches to help you there.


> so I've tried to tell you politely how to do that.

This feedback is generally fine.


> If you're not willing to do it,

My willingness is depending on also some factors.


> though, this is where it ends.

I hope that a bit more clarification can improve the situation.


> And attempts to convince me that I may not want my life to be easier
> after all are not likely to succeed.

We usually want that life will become more comfortable.

I chose to contribute something to Linux source files for this purpose.
My knowledge evolved in the way that I am using some tools for
static source code analysis. Such advanced tools can point various
change opportunities out. I picked a few special search patterns up.
It happened then that hundreds of source files were found which contain
update candidates. I am trying to inform the corresponding developers
about improvement possibilities in affected systems.


Further challenges are relevant then as usual.

* Handling of the search process and their results

* Communication between contributors


Search patterns can occasionally be categorised as "too special".
The software technology contains also the risk for showing "false positives".

The reactions of code reviewers are varying between rejection and acceptance.
Now I would like to determine again which details of the proposed changes
have got a higher chance for acceptance.

The discussed concrete patch series is just another example for usual
difficulties or more interesting software development challenges.
I hope that they can be resolved in a systematic way.
I sent analysis results as a series of small software updates. I find
it important to understand them also in the way that they belong to
software design patterns. I can imagine that it is harder to recognise
the involved patterns from the presented combination of update steps.

Would you like to check and clarify these patterns once more
before the desired improvements will happen (in a software area you maintain)?


So there are further constraints to consider. My software development experience
leaded me to a very specific kind of patch granularity here.
My software development interest evolved also in the way that I dared
to fiddle with the source files "drivers/acpi/processor_perflib.c"
and "drivers/acpi/processor_throttling.c" yesterday.
The consequence is that I would to publish a corresponding series
of 30 update steps for integration into another source code repository.
It seems that I need to wait a bit more for the next contribution attempt
before the change acceptance will fit to such an approach.

Regards,
Markus

Powered by blists - more mailing lists