Hello, On Mon, 21 Jul 2008, Paul Moore wrote: > On Monday 21 July 2008 9:08:16 am Vesa-Matti J Kari wrote: > > Sure. But is that really a valid argument to block the changes that > > attempt to bring *at least some* unity to the code? > > I obviously thought so which is why I voted "NO". Not all change is > good, even if the intentions are correct. Agreed. > All change brings risk and if there is not an advantage to offset that > risk then all you are doing is adding risk into the system. Risk of > runtime bugs, Well, we do have a class of patches that can be applied without risking the system that much. The class consists of (at least) the following cases: 1) Code formatting fixes that affect only whitespace. I guess these are known as "whitespace patches", and can be considered trivial. 2) Code fixes that transform statements into semantically equivalent statements in a such a way that the code generated by the compiler is equivalent before and after the patch is applied. I don't know whether that class has any common name, but it is pretty much risk free, because you just have two source trees; the original and the patched, and after patching you compare the generated object files in both trees. If they are identical, then the patching has been a safe operation to do. But, yes, you say: > risk of merging/porting bugs, etc. Merging can indeed be problematic even with the class mentioned above. > I don't have a problem with fixing significant style problems in the > code; I agreed with Eric's massive whitespace cleanup earlier this year > and I think your patch to convert to '\0' NULL terminators is a good > one. However, I do draw the line at patches that only rename > variables, especially the conversion of 'idx' to 'i'. That's all right. It's good to know where the limits are. > [...] > Another thought, if you want to help improve the code, especially > SELinux, I would encourage you to look at the ToDo lists: > > * http://www.selinuxproject.org/page/Kernel_Development#To_Do_List > * http://www.selinuxproject.org/page/Userspace_Development > > ... and attempt to work on one of the issues on those lists. I would be > more than happy to help if you get stuck and need a hand. Thanks for the links. The problem is I have to learn to walk properly before I can run. Only the very first kernel problem seemed solvable by me, and it would probably take lots of time, and I'm not 100% confident about the solution either. For sure I hope to be able to contribute more than just trivial patches, but as I go through the code, I'll pick up things that are easily fixed without any extra effort. Those are mostly boring fixes, but they should help too, as it enables the more experienced developers to focus on the more real, high-level problems concerning the overall architecture and so on. But yeah, I have to say I have found the "SELinux by Example" book very useful. The code makes much more sense when you have a general description of the system. Best regards, vmk -- ************************************************************************ Tietotekniikkaosasto / Helsingin yliopisto IT Department / University of Helsinki ************************************************************************ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
