>>>> Here needs a NULL check. >> quite obvious? I suggest to consider another fine-tuning for the wording also around such “obvious” programming items.
>>> I find this change description questionable >>> (despite of a reasonable patch subject). I got further development concerns. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=a10c9c710f9ecea87b9f4bbb837467893b4bef01#n129 * Were changes mixed for different issues according to the diff code? * I find it safer here to split specific changes into separate update steps for a small patch series. * Will the addition of the desired null pointer check qualify for the specification of the tag “Fixes”? >>> Will a patch change log be helpful here? >> I realized I should write some change log, and the change log was >> meaningless. Will any more adjustments happen for the discussed update suggestion after the third patch version? > The changelog is fine IMO. The point of a changelog is to tell a > reader doing git archeology why a change happened and this is > sufficent for that. We might stumble on a different understanding for the affected “change logs”. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=a10c9c710f9ecea87b9f4bbb837467893b4bef01#n751 Would you like to follow the patch evolution a bit easier? Regards, Markus
