On Wed, Jan 03, 2018 at 09:41:04AM +0100, SF Markus Elfring wrote: > > I understand it can be frustrating to encounter different policies > > across kernel maintainers. > > The change acceptance is varying for special transformation patterns. > > > > You'll even run in to this with maintainers of the same subsystem > > from time to time. > > Interesting, isn't it? > > > > I'm supportive of cleaning up old code in general, > > Nice. > > > > and we routinely apply such patches as these developed with cocci. > > Good to know … > > > > 1. This is init code )so any space savings is short lived) > > Would you dare to achieve another small improvement there? > > > > So it isn't that we place a low value on coding style guidelines, > > but rather we place higher value on not perturbing code > > I can follow this view in principle. > > > > we can't fully test without a demonstrable functional reasons to do so. > > How do you think about to get a bit nicer run time characteristics? If this was code that affected all systems, the impact would be greater - and it would be much easier to test. As it applies only to Thinkpad systems, far fewer total systems are affected, and it is much harder to test/verify. For something like this, we (Andy and I) will typically defer to the driver-specific maintainer. Henrique has declined the patch, and I think the reasoning is defensible. If you feel that is the wrong call, you will need to present convincing evidence to Henrique that this is worth the risk. From what I've seen of the patch series thus far... I don't think the advantages can be argued to outweigh the risks - or that it would be worth the effort. Henrique, I'm going to stop there and let you chime in if you feel differently about any of the above. -- Darren Hart VMware Open Source Technology Center ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
