Toward a kernel maintainer's guide
Toward a kernel maintainer's guide
Posted Nov 27, 2018 16:01 UTC (Tue) by rweikusat2 (subscriber, #117920)In reply to: Toward a kernel maintainer's guide by mfuzzey
Parent article: Toward a kernel maintainer's guide
Empirically, this model has worked exceedingly well for a long time, hence, there's no reasonable justification to change it now just because that's unfamiliar to certain people. The only "pain" involved here is if style conventions are being enforced (or sometimes enforced, depending on the social situation) which aren't documented anywhere: There's no way someone who isn't already familiar with whatever petty regulations are considered important can divine knowledge about them. Hence, trainwrecks are guaranteed to occur: Someone's being annoyed that things were done differently despite "everybody knows that THIS is the proper colour for a bikeshed!", someone else finds himself suddenly stepping on hidden landmines despite painstakingly trying to do everything "in the right way".
As the paragraph above probably does (and certainly should) suggest, ideally, there would be no (or at least as few as possible) petty regulations at all. That different conventions about these can successfully coexist suggests that they aren't really necessary.
Posted Nov 27, 2018 16:56 UTC (Tue)
by mfuzzey (subscriber, #57966)
[Link] (1 responses)
Yes, that's what I meant by inertia
>The only "pain" involved here is if style conventions are being enforced (or sometimes enforced, depending on the social situation) which aren't documented anywhere
Obviously if they aren't being enforced there is no pain :)
>As the paragraph above probably does (and certainly should) suggest, ideally, there would be no (or at least as few as possible) petty regulations at all. That different >
Indeed, I completely agree with this. I wasn't suggesting that there should be a great "christmas tree debate" kernel wide. But that a rule should either be considered sufficiently important to be in the global CodingStyle or it should not exist.
Posted Nov 27, 2018 22:59 UTC (Tue)
by rweikusat2 (subscriber, #117920)
[Link]
I don't think that's realistic, especially considering that some maintainers enforce coding style regulations which contradict what's written in the CodingStyle text (Patrick "This function is used only once. Get rid of it" McHardy being an example I personally encountered). OTOH, expecting outside contributors (or prospective outside contributors) to read throuhg a few years of a large number of high-volume mailing lists in order to discover "undocumented preferences" of over 1000 people is also not realistic. That's nothing but a camouflaged and guarded "No entry"-sign.
There must be a way for someone to determine which guidelines to follow, ie, a document listing them. Otherwise, one can only try to imitate how the other code is written and that's not a trusty guide: Some "style regulations" are actually not about style at all, they mandate functional differences, even to the point of requiring that code works in an unlogical way. Eg, some people are strongly convinced that all loops ought to be pre-test loops. I don't think so because the initial state is often known and testing a condition known be either true or false seems absurd to me. Nevertheless, I'd gladly follow such a rule if someone considered it important. But there's no way to infer this from code.
Toward a kernel maintainer's guide
But if they are enforced, even if documented, it is a pain to those that work in multiple subsystems whereas those that only work in one probably never notice.
>conventions about these can successfully coexist suggests that they aren't really necessary.
Toward a kernel maintainer's guide
> But that a rule should either be considered sufficiently important to be in the global CodingStyle or it should not exist.