linux-kernel - Re: Adjustments for a lot of function implementations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Oct 2017 09:27:56 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Hans Verkuil <hverkuil@...all.nl>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org
Cc:     Julia Lawall <julia.lawall@...6.fr>, Jan Kara <jack@...e.cz>,
        Lorenzo Stoakes <lstoakes@...il.com>,
        Michal Hocko <mhocko@...e.com>,
        Muralidharan Karicheri <mkaricheri@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: Adjustments for a lot of function implementations

>>>> 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