>> My update selection can contain also trivial adjustments.
>
> The *really* trivial ones were applied.
Did you leave a few from this change category over which could be integrated
a bit later?
Regards,
Markus
> So, that's all. Think how the things can be improved in your side,
I know a few possibilities here.
> not blaming others.
But I know also a few other approaches where higher level development
tools help to improve the patch review process in significant ways
for trusted system environments.
On Tue, 28 Nov 2017 21:18:01 +0100,
SF Markus Elfring wrote:
>
> >> Would you like to discuss the circumstances for the one glitch
> >> to which you might refer to?
> >
> > No need for discussion.
>
> I disagree to this view again.
So, that's all. Think how the things can be improved in your s
>> Would you like to discuss the circumstances for the one glitch
>> to which you might refer to?
>
> No need for discussion.
I disagree to this view again.
> It's difficult to recover a lost trust.
I can follow this view to some degree.
But I find that the current might point also other weak
On Tue, 28 Nov 2017 20:57:17 +0100,
SF Markus Elfring wrote:
>
> >> At which point did you change you mind for any of my (higher level)
> >> patches?
> >
> > Since your patch brought a regression in the past.
>
> Would you like to discuss the circumstances for the one glitch
> to which you migh
>> At which point did you change you mind for any of my (higher level) patches?
>
> Since your patch brought a regression in the past.
Would you like to discuss the circumstances for the one glitch
to which you might refer to?
Regards,
Markus
On Tue, 28 Nov 2017 20:48:52 +0100,
SF Markus Elfring wrote:
>
> > Because it turned out that your patch can be wrong and broken.
>
> At which point did you change you mind for any of my (higher level) patches?
Since your patch brought a regression in the past.
Takashi
> Because it turned out that your patch can be wrong and broken.
At which point did you change you mind for any of my (higher level) patches?
Regards,
Markus
On Tue, 28 Nov 2017 20:08:13 +0100,
SF Markus Elfring wrote:
>
> >> Examples:
> >> * ALSA: cs5530: Use common error handling code in snd_cs5530_probe()
> >> https://lkml.org/lkml/2017/11/18/266
> >> https://patchwork.kernel.org/patch/10064945/
> >>
> >> https://lkml.kernel.org/r/
> >
> > T
>> Examples:
>> * ALSA: cs5530: Use common error handling code in snd_cs5530_probe()
>> https://lkml.org/lkml/2017/11/18/266
>> https://patchwork.kernel.org/patch/10064945/
>>
>> https://lkml.kernel.org/r/
>
> This is no trivial patch.
Why do you find this one more challenging now than a s
On Tue, 28 Nov 2017 18:15:34 +0100,
SF Markus Elfring wrote:
>
> >> Do you want that I point any other patch out which you could find
> >> easier to handle again?
> >
> > Only if they got tested and/or got reviewed by others.
>
> Would you find any of the following update suggestions trivial eno
>> Do you want that I point any other patch out which you could find
>> easier to handle again?
>
> Only if they got tested and/or got reviewed by others.
Would you find any of the following update suggestions trivial enough
to integrate them?
Examples:
* ALSA: cs5530: Use common error handling
On Tue, 28 Nov 2017 17:40:18 +0100,
SF Markus Elfring wrote:
>
> > No-testing is the worst case.
>
> Free software development can occasionally mean that system tests
> can also be performed by a person who is different from the
> initial programmer.
So ask someone for testing. If you can find
> No-testing is the worst case.
Free software development can occasionally mean that system tests
can also be performed by a person who is different from the
initial programmer.
>> I am unsure if acceptable test results will ever be published for this
>> software module.
>
> Then forget about y
On Tue, 28 Nov 2017 17:15:27 +0100,
SF Markus Elfring wrote:
>
> > Because I didn't see any test result from you,
>
> This is correct so far.
>
>
> > so I can't trust you.
>
> This view did not hinder you to integrate some of my update suggestions
> which you found easier to handle.
The reall
> Because I didn't see any test result from you,
This is correct so far.
> so I can't trust you.
This view did not hinder you to integrate some of my update suggestions
which you found easier to handle.
>> Which test configurations would you trust finally?
>
> Do test whatever like the users
On Tue, 28 Nov 2017 16:01:47 +0100,
SF Markus Elfring wrote:
>
> >>> Give the test result before speaking too much.
> >>
> >> Which concrete data do you expect here?
> >
> > Depends on the result.
>
> How can this vary?
How? Because I didn't see any test result from you, so I can't trust
you.
>>> Give the test result before speaking too much.
>>
>> Which concrete data do you expect here?
>
> Depends on the result.
How can this vary?
> The bottom line is that you run your patched kernel on the real hardware
Which test configurations would you trust finally?
> or equivalent (VM or
On Tue, 28 Nov 2017 15:44:07 +0100,
SF Markus Elfring wrote:
>
> >> How would such a setting influence my trust level for your subsystem
> >> maintenance?
> >
> > Give the test result before speaking too much.
>
> Which concrete data do you expect here?
Depends on the result. The bottom line
>> How would such a setting influence my trust level for your subsystem
>> maintenance?
>
> Give the test result before speaking too much.
Which concrete data do you expect here?
> It's already way too contra-productive, just chatting.
I got an other view.
I hope that we can achieve a better
On Tue, 28 Nov 2017 15:33:45 +0100,
SF Markus Elfring wrote:
>
> > If *you* do introduce automatic testing for *your* patches,
> > then I appreciate it.
>
> How would such a setting influence my trust level for your subsystem
> maintenance?
Give the test result before speaking too much. It's a
> If *you* do introduce automatic testing for *your* patches,
> then I appreciate it.
How would such a setting influence my trust level for your subsystem
maintenance?
> I can trust my system for my purpose.
I need to trust it also somehow.
Regards,
Markus
On Tue, 28 Nov 2017 15:19:55 +0100,
SF Markus Elfring wrote:
>
> >> How would you notice that a corresponding system test worked
> >> in reasonable ways?
> >
> > It needs a trust to the patch author or the tester who reported that
> > it worked.
>
> Can this aspect vary over time?
Not really.
>> How would you notice that a corresponding system test worked
>> in reasonable ways?
>
> It needs a trust to the patch author or the tester who reported that
> it worked.
Can this aspect vary over time?
> The test result should be mentioned concisely.
How do you think about to introduce acce
On Tue, 28 Nov 2017 14:17:00 +0100,
SF Markus Elfring wrote:
>
> >> Which test results would you like to see or hear (!) from a real device
> >> (or a configuration in a virtual machine)?
> >
> > I don't mind either case as long as the test works.
>
> How would you notice that a corresponding sy
>> Which test results would you like to see or hear (!) from a real device
>> (or a configuration in a virtual machine)?
>
> I don't mind either case as long as the test works.
How would you notice that a corresponding system test worked
in reasonable ways?
>> I find such a development tool ver
>> Can you get the impression that the shown transformation patterns were
>> correctly applied for the source file “sound/pci/nm256/nm256.c”?
>
> Have you tested the driver?
Which results do you expect from a corresponding system test?
> Please don't "improve" working drivers unless
I am tryin
On Tue, 28 Nov 2017 14:00:39 +0100,
SF Markus Elfring wrote:
>
> >> Are any additional communication interfaces helpful?
> >
> > No idea.
>
> * Can an ordinary telephone call help?
>
> * Will a meeting during a Linux conference be needed?
No and no.
> >> Have you got any steps in mind for an
>> Are any additional communication interfaces helpful?
>
> No idea.
* Can an ordinary telephone call help?
* Will a meeting during a Linux conference be needed?
>> Have you got any steps in mind for an improved “feeling” or “assurance”?
>
> Just do proper testing. Either on a real hardware
On Tue, 28 Nov 2017 13:33:48 +0100,
SF Markus Elfring wrote:
>
> >> It seems then that you can not get the kind of information you might be
> >> looking for
> >> at the moment from me (alone).
> >
> > No, the patch itself speaks.
>
> Are we still trying to clarify (only) two possible update ste
>> It seems then that you can not get the kind of information you might be
>> looking for
>> at the moment from me (alone).
>
> No, the patch itself speaks.
Are we still trying to clarify (only) two possible update steps
for this software module?
> If you get more reviewed-by from others, it m
On Tuesday 28 November 2017, SF Markus Elfring wrote:
> There is a general source code transformation pattern involved.
> So I find that it is systematic.
>
> But I did not dare to develop a script variant for the semantic patch
> language (Coccinelle software) which can ha
On Tue, 28 Nov 2017 10:50:21 +0100,
SF Markus Elfring wrote:
>
> >> There can be additional means be used to reduce the probability
> >> of undesired side effects.
> >
> > Irrelevant,
>
> I got an other opinion here.
Not from me.
> > it doesn't fix a bug,
>
> Did I suggest to correct a coding
>> There can be additional means be used to reduce the probability
>> of undesired side effects.
>
> Irrelevant,
I got an other opinion here.
> it doesn't fix a bug,
Did I suggest to correct a coding style “bug”?
> nor dramatic improvement.
I agree that the change could be small only for th
On Tue, 28 Nov 2017 09:19:48 +0100,
SF Markus Elfring wrote:
>
> There is a general source code transformation pattern involved.
> So I find that it is systematic.
>
> But I did not dare to develop a script variant for the semantic patch
> language (Coccinelle software) wh
There is a general source code transformation pattern involved.
So I find that it is systematic.
But I did not dare to develop a script variant for the semantic patch
language (Coccinelle software) which can handle all special use cases
as a few of them are already dem
On Thu, 16 Nov 2017 20:30:24 +0100,
SF Markus Elfring wrote:
>
> >> There is a general source code transformation pattern involved.
> >> So I find that it is systematic.
> >>
> >> But I did not dare to develop a script variant for the semantic patch
> >> language (Coccinelle software) which can ha
>> There is a general source code transformation pattern involved.
>> So I find that it is systematic.
>>
>> But I did not dare to develop a script variant for the semantic patch
>> language (Coccinelle software) which can handle all special use cases
>> as a few of them are already demonstrated in
On Thu, 16 Nov 2017 18:48:43 +0100,
SF Markus Elfring wrote:
>
> >> Two update suggestions were taken into account
> >> from static source code analysis.
> >
> > Markus, I'd apply this kind of patches only when they are really
> > tested on the hardware,
>
> I can not test all software and hardw
>> Two update suggestions were taken into account
>> from static source code analysis.
>
> Markus, I'd apply this kind of patches only when they are really
> tested on the hardware,
I can not test all software and hardware combinations (so far)
for which I dare to show change possibilities.
> o
On Thu, 16 Nov 2017 18:05:27 +0100,
SF Markus Elfring wrote:
>
> From: Markus Elfring
> Date: Thu, 16 Nov 2017 18:00:18 +0100
>
> Two update suggestions were taken into account
> from static source code analysis.
Markus, I'd apply this kind of patches only when they are really
tested on the har
From: Markus Elfring
Date: Thu, 16 Nov 2017 18:00:18 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Adjust five function calls together with a variable assignment
Use common error handling code in snd_nm256_probe()
sound/pci/nm256
42 matches
Mail list logo
