lkml.org 
[lkml]   [2017]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Adjustments for a lot of function implementations
From
Date
>>>> but will reject the others, not just this driver but all of them
>>>> that are currently pending in our patchwork (https://patchwork.linuxtv.org).

I find it very surprising that you rejected 146 useful update suggestions
so easily.


>>>> Feel free to repost, but only if you organize the patch as either fixing
>>>> the same type of issue for a whole subdirectory (media/usb, media/pci, etc)
>>
>> Just for the record, while this may work for media, it won't work for all
>> subsystems. One will quickly get a complaint that the big patch needs to
>> go into multiple trees.
>
> For the record: this only applies to drivers/media.

What does this software area make it so special in comparison to
other Linux subsystems?


> We discussed what do to with series like this during our media summit
> last Friday and this was the conclusion of that.

* Have you taken any other solution approaches into account than
a quick “rejection”?

* Could your reaction have been different if the remarkable number of
change possibilities were sent by different authors (and not only me)?

* How should possibly remaining disagreements about affected implementation
details be resolved now?

* Are you looking for further improvements around development tools
like “patchwork” and “quilt”?

* Will you accept increasing risks because of bigger patch sizes?


>>>> or fixing all issues for a single driver.
>>>
>>> I find that I did this already.

* Can such an information lead to differences in the preferred patch granularity?

* How do you think about this detail?


>>>> Actual bug fixes (like the null pointer patch in this series) can still be posted as
>>>> separate patches, but cleanups shouldn't.
>>>
>>> I got an other software development opinion.

How would you ever like to clean up stuff in affected source files
which was accumulated (or preserved somehow) over years?


>>>> Just so you know, I'll reject any future patch series that do not follow these rules.

I guess that this handling will trigger more communication challenges.


>>>> Just use common sense when posting these things in the future.

Our “common sense” seems to be occasionally different in significant ways.


>>>> I would also suggest that your time might be spent more productively
>>>> if you would work on some more useful projects.

I distribute my software development capacity over several areas.
Does your wording indicate a questionable signal for further contributions?

Regards,
Markus

\
 
 \ /
  Last update: 2017-10-31 09:30    [W:0.312 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site