From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org
Cc: Julia Lawall <julia.lawall@lip6.fr>, Jan Kara <jack@suse.cz>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Michal Hocko <mhocko@suse.com>,
Muralidharan Karicheri <mkaricheri@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: Adjustments for a lot of function implementations
Date: Tue, 31 Oct 2017 09:27:56 +0100 [thread overview]
Message-ID: <f4bd5363-894f-57ee-a557-555ac700ea1a@users.sourceforge.net> (raw)
In-Reply-To: <ebf37d57-38c6-b3de-5a66-dbb1c13fd63a@xs4all.nl>
>>>> 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
prev parent reply other threads:[~2017-10-31 8:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-24 10:20 [PATCH 0/6] [media] omap_vout: Adjustments for three function implementations SF Markus Elfring
2017-09-24 10:22 ` [PATCH 1/6] [media] omap_vout: Delete an error message for a failed memory allocation in omap_vout_create_video_devices() SF Markus Elfring
2017-09-24 10:35 ` Joe Perches
2017-09-24 10:24 ` [PATCH 2/6] [media] omap_vout: Improve a size determination in two functions SF Markus Elfring
2017-09-24 10:26 ` [PATCH 3/6] [media] omap_vout: Adjust a null pointer check " SF Markus Elfring
2017-09-24 10:28 ` [PATCH 4/6] [media] omap_vout: Fix a possible null pointer dereference in omap_vout_open() SF Markus Elfring
2017-09-24 10:30 ` [PATCH 5/6] [media] omap_vout: Delete an unnecessary variable initialisation " SF Markus Elfring
2017-09-24 10:33 ` [PATCH 6/6] [media] omap_vout: Delete two unnecessary variable initialisations in omap_vout_probe() SF Markus Elfring
2017-10-30 8:36 ` [PATCH 0/6] [media] omap_vout: Adjustments for three function implementations Hans Verkuil
2017-10-30 9:16 ` Adjustments for a lot of " SF Markus Elfring
2017-10-30 9:47 ` Julia Lawall
2017-10-30 9:57 ` Hans Verkuil
2017-10-30 10:40 ` SF Markus Elfring
2017-10-30 10:48 ` Hans Verkuil
2017-10-30 11:41 ` SF Markus Elfring
2017-11-26 19:06 ` SF Markus Elfring
2018-01-08 11:44 ` SF Markus Elfring
2018-02-02 9:55 ` SF Markus Elfring
2018-02-02 10:29 ` Hans Verkuil
2018-02-02 12:30 ` SF Markus Elfring
2018-02-10 8:39 ` SF Markus Elfring
2017-10-31 8:27 ` SF Markus Elfring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4bd5363-894f-57ee-a557-555ac700ea1a@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=hverkuil@xs4all.nl \
--cc=jack@suse.cz \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lstoakes@gmail.com \
--cc=mchehab@kernel.org \
--cc=mhocko@suse.com \
--cc=mkaricheri@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).