> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.
Do any contributors get into the mood to take another look at software updates
from my selection of change possibilities in a more constructive way?
Do you need any additional development resources?
Regards,
Markus
On 02/02/18 10:55, SF Markus Elfring wrote:
>> ??? I did that: either one patch per directory with the same type of change,
>> or one patch per driver combining all the changes for that driver.
>
> Do any contributors get into the mood to take another look at software updates
> from my selection of change possibilities in a more constructive way?
>
> Do you need any additional development resources?
One last time: either post per-driver patches with all the cleanups for a driver
in a single patch, or a per-directory patch (drivers/media/pci, usb, etc) doing
the same cleanup for all drivers in that directory.
I prefer the first approach, but it's up to you.
We don't have the time to wade through dozens of one-liner cleanup patches.
I don't understand what is so difficult about this.
Regards,
Hans
> One last time: either post per-driver patches with all the cleanups for a driver
> in a single patch,
I preferred to offer source code adjustments according to specific transformation
patterns mostly for each software module separately (also in small patch series).
> or a per-directory patch (drivers/media/pci, usb, etc) doing the same cleanup
> for all drivers in that directory.
I am curious if bigger patch packages would be easier to get accepted.
Or would you get frightened still by any other change combination?
> I prefer the first approach,
We have got different preferences for a safe patch granularity.
> but it's up to you.
I imagine that there are more development factors involved.
> We don't have the time to wade through dozens of one-liner cleanup patches.
It is usual that integration of update suggestions will take some time.
How would the situation change if I would dare to regroup possible update steps?
> I don't understand what is so difficult about this.
There are communication difficulties to consider since your terse information
from your conference meeting.
If you would insist on patch squashing, would you dare to use a development tool
like “quilt fold” also on your own once more?
Regards,
Markus
>> Do any contributors get into the mood to take another look at software updates
>> from my selection of change possibilities in a more constructive way?
>>
>> Do you need any additional development resources?
>
> One last time: either post per-driver patches with all the cleanups for a driver
> in a single patch,
I find such a change combination unsafe.
> or a per-directory patch (drivers/media/pci, usb, etc) doing the same cleanup
> for all drivers in that directory.
Would you dare to apply any (of my) scripts for the semantic patch language
directly on the whole directory for multi-media software?
> I prefer the first approach, but it's up to you.
Can you handle bigger patches really better than similar patch series?
> We don't have the time to wade through dozens of one-liner cleanup patches.
Are there any further possibilities to consider around consequences
from a general change resistance?
Will any development (or management) tools like “quilt fold” make the regrouping
of possible update steps more convenient and safer?
Regards,
Markus