Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1490649 > unrolled thread

[PATCH 3/4] Input-gameport: Add the macro "pr_fmt" for module "joydump"

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 3/4] Input-gameport: Add the macro "pr_fmt" for module  "joydump" SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-24 15:50 +0200
    Re: [PATCH 3/4] Input-gameport: Add the macro "pr_fmt" for module  "joydump" Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-09-24 18:50 +0200
      Re: [PATCH 3/4] Input-gameport: Add the macro "pr_fmt" for module  "joydump" SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-24 19:00 +0200
        Re: [PATCH 3/4] Input-gameport: Add the macro "pr_fmt" for module  "joydump" Joe Perches <joe@perches.com> - 2016-09-24 19:10 +0200
          Re: Input-gameport: Add the macro "pr_fmt" for module "joydump" SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-24 19:50 +0200
            Re: Input-gameport: Add the macro "pr_fmt" for module "joydump" Joe Perches <joe@perches.com> - 2016-09-24 20:10 +0200
              Re: Input-gameport: Add the macro "pr_fmt" for module "joydump" SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-24 20:50 +0200

#1490649 — [PATCH 3/4] Input-gameport: Add the macro "pr_fmt" for module "joydump"

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 24 Sep 2016 14:30:44 +0200

Add a definition for the macro "pr_fmt" so that its information can be used
for consistent message output.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/input/joystick/joydump.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/joystick/joydump.c b/drivers/input/joystick/joydump.c
index f9f6cbe..a38f10e 100644
--- a/drivers/input/joystick/joydump.c
+++ b/drivers/input/joystick/joydump.c
@@ -27,6 +27,8 @@
  * Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include <linux/module.h>
 #include <linux/gameport.h>
 #include <linux/kernel.h>
-- 
2.10.0

[toc] | [next] | [standalone]

#1490682

On Sat, Sep 24, 2016 at 03:48:54PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 24 Sep 2016 14:30:44 +0200
> 
> Add a definition for the macro "pr_fmt" so that its information can be used
> for consistent message output.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  drivers/input/joystick/joydump.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/input/joystick/joydump.c b/drivers/input/joystick/joydump.c
> index f9f6cbe..a38f10e 100644
> --- a/drivers/input/joystick/joydump.c
> +++ b/drivers/input/joystick/joydump.c
> @@ -27,6 +27,8 @@
>   * Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
>   */
>  
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +

Why did you split it off from the patch where you attempt to use it?
What good does this change do on its own?

>  #include <linux/module.h>
>  #include <linux/gameport.h>
>  #include <linux/kernel.h>
> -- 
> 2.10.0
> 

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1490685

>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
> 
> Why did you split it off from the patch where you attempt to use it?

I chose a special patch granularity once again.


> What good does this change do on its own?

I find that it is a preparation. - If this addition could not be accepted,
the following update step would also be discussed under an other perspective,
wouldn't it?

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#1490688

On Sat, 2016-09-24 at 18:55 +0200, SF Markus Elfring wrote:
> > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > Why did you split it off from the patch where you attempt to use it?
> I chose a special patch granularity once again.
> > What good does this change do on its own?
> I find that it is a preparation. - If this addition could not be accepted,
> the following update step would also be discussed under an other perspective,
> wouldn't it?

It's purposeless, creates unnecessary patches to review
and generally wastes other people's time.

Please don't purposefully waste other people's time.
It makes your patch proposals _less_ likely to be applied.

[toc] | [prev] | [next] | [standalone]

#1490702 — Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

>> I find that it is a preparation. - If this addition could not be accepted,
>> the following update step would also be discussed under an other perspective,
>> wouldn't it?
> 
> It's purposeless, creates unnecessary patches to review
> and generally wastes other people's time.

I have got an other opinion about this.


> Please don't purposefully waste other people's time.

I do not want to "waste" your time. - But I can imagine that I stress your
software development attention to some degree as I am publishing a significant
number of update suggestions according to a bit of static source code analysis.


> It makes your patch proposals _less_ likely to be applied.

The acceptance varies as usual.


I see also another option.

* Can the first three update steps from this small patch series be integrated
  while the fourth needs further adjustments (where I went a bit too far)?

* Do you prefer to squash the last two update steps together?

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#1490706 — Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

On Sat, 2016-09-24 at 19:45 +0200, SF Markus Elfring wrote:
> > It's purposeless, creates unnecessary patches to review
> > and generally wastes other people's time.
> I have got an other opinion about this.

Nice for you, not nice for others that have to act on
your patch proposals to get them forwarded upstream.

> > Please don't purposefully waste other people's time.
> I do not want to "waste" your time.

When a chorus of voices says to you that you are wasting
their time, perhaps you listen to their song.

> > It makes your patch proposals _less_ likely to be applied.
> The acceptance varies as usual.

Usual for whom?

It seems to me your patch proposals have a relatively high
unapplied patch percentage and there is an increase in the
number of upstream maintainers that ignore you.

> I see also another option.
> 
> * Can the first three update steps from this small patch series be integrated
>   while the fourth needs further adjustments (where I went a bit too far)?
> 
> * Do you prefer to squash the last two update steps together?

Yes, the overall number of patches should be minimized when
the suggested patches are highly related.

[toc] | [prev] | [next] | [standalone]

#1490716 — Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

> When a chorus of voices says to you that you are wasting
> their time, perhaps you listen to their song.

I am listening to some degree. - I guess that I am making some decisions
and conclusions in a way that you would prefer to be different.

I know that my update suggestions won't be liked by all contributors.


> It seems to me your patch proposals have a relatively high
> unapplied patch percentage

I agree here. - This impression can occur for a while.

I find that this situation is hardly avoidable according to my evolving number
of update suggestions.
In which time frames do you look for the corresponding software development process?


> and there is an increase in the number of upstream maintainers that ignore you.

It's a pity. - I hope that the corresponding software development can still
be continued in constructive ways.


> Yes, the overall number of patches should be minimized when
> the suggested patches are highly related.

I have got a special opinion about patch squashing. But I can consider it
also for this update step when a corresponding consensus could be
achieved between contributors.

Regards,
Markus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web