linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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