On Mon 2023-08-07 21:47:17, Rasmus Villemoes wrote: > On 07/08/2023 16.58, Andy Shevchenko wrote: > > On Mon, Aug 07, 2023 at 04:31:37PM +0200, Petr Mladek wrote: > >> On Sat 2023-08-05 20:50:25, Andy Shevchenko wrote: > >>> Sorting headers alphabetically helps locating duplicates, and > >>> make it easier to figure out where to insert new headers. > >> > >> I agree that includes become a mess after some time. But I am > >> not persuaded that sorting them alphabetically in random source > >> files help anything. > >> > >> Is this part of some grand plan for the entire kernel, please? > >> Is this outcome from some particular discussion? > >> Will this become a well know rule checked by checkpatch.pl? > >> > >> I am personally not going to reject patches because of wrongly > >> sorted headers unless there is some real plan behind it. > >> > >> I agree that it might look better. An inverse Christmas' tree > >> also looks better. But it does not mean that it makes the life > >> easier. > > > > It does from my point of view as maintainability is increased. > > > >> The important things are still hidden in the details > >> (every single line). > >> > >> From my POV, this patch would just create a mess in the git > >> history and complicate backporting. > >> > >> I am sorry but I will not accept this patch unless there > >> is a wide consensus that this makes sense. > > > > Your choice, of course, But I see in practice dup headers being > > added, or some unrelated ones left untouched because header list > > mess, and in those cases sorting can help (a bit) in my opinion. > > I agree with Andy on this one. There doesn't need to be some grand > master plan to apply this to the entire kernel, but doing it to > individual files bit by bit does increase the maintainability. And I > really don't buy the backporting argument. Sure, backporting some patch > across the release that does the sorting is harder - but then, > backporting the sorting patch itself is entirely trivial (maybe not the > textual part, but redoing the semantics of it is). _However_, > backporting a patch from release z to release y, both of which being > later than the release x that did the sorting, is going to be _easier_. > It also reduces merge conflicts - that's also why lots of Makefiles are > kept sorted. I am afraid that we will not find a consensus here. I agree that the sorting has some advantage. But I would still like to get some wider agreement on this move from other subsystem. It is a good candidate for a mass change which would be part of some plan. I want to avoid reshuffling this more times according to personal preferences. And I do not want to add this cosmetic subsystem specific requirement. Best Regards, Petr
