On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote: > > > On Sun, 11 Sep 2016, Jarkko Sakkinen wrote: > > > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote: > > > Constify local structures. > > > > > > The semantic patch that makes this change is as follows: > > > (http://coccinelle.lip6.fr/) > > > > Just my two cents but: > > > > 1. You *can* use a static analysis too to find bugs or other issues. > > 2. However, you should manually do the commits and proper commit > > messages to subsystems based on your findings. And I generally think > > that if one contributes code one should also at least smoke test changes > > somehow. > > > > I don't know if I'm alone with my opinion. I just think that one should > > also do the analysis part and not blindly create and submit patches. > > All of the patches are compile tested. And the individual patches are Compile-testing is not testing. If you are not able to test a commit, you should explain why. > submitted to the relevant maintainers. The individual commit messages > give a more detailed explanation of the strategy used to decide that the > structure was constifiable. It seemed redundant to put that in the cover > letter, which will not be committed anyway. I don't mean to be harsh but I do not care about your thought process *that much* when I review a commit (sometimes it might make sense to explain that but it depends on the context). I mostly only care why a particular change makes sense for this particular subsystem. The report given by a static analysis tool can be a starting point for making a commit but it's not sufficient. Based on the report you should look subsystems as individuals. > julia /Jarkko -- 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
