>> For the next pile of driver patches _please_ talk with driver maintainers >> before starting to create&submit patches. Did the software development discussion start a bit here? Would you like to support an other "talking style" on a conference like in Berlin next month? >> Like I said I won't take them, It's a pity. >> and many of your changes are not clear-cut at all, I know that specific update suggestions could be interpreted as controversial. >> so I expect many driver maintaines also won't take them. I am curious on useful responses. >> Again, your contributions are welcome, Thanks for another bit of constructive feedback. >> but blindly following suggestions from code checkers in drivers I propose to dare another look at corresponding information sources. >> you cant test isn't really all that useful. I have got an other impression. How many improvements can still be achieved by usual (advanced) collaboration techniques for free software development? >> At the scale you're doing it, I think it's mostly wasting everyone's time I hope not. > :( I'd like to avoid that. I am going to point more update opportunities out also for various Linux software. > I second that. Thanks for your opinion on this issue. > After a very quick review, I see that the series splits related changes > in multiple patches. I chose a specific patch granularity for this proposal. > I've already commented in reply to another series submitted by Markus > that patches should then be combined. Will such a combination depend on any more agreements between the involved contributors? > I will thus ignore this series completely for the time being. I hope that you can give similar ideas a second chance somehow. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
