| Message ID | 3345f7c1-b823-a819-aabf-5b4990068075@users.sourceforge.net (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
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 >
>> +#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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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>