I'm really getting tired of this! > Because you are not even sure of what you submitted is good for the kernel > ? No, because we need to get a feeling of what makes sense for all these options first. I'd rather do the learning-by-doing thing here and implement what makes sense than braindead frameworks. > I think this has been done completely wrong, first all the extra > warnings got in (without a detailed impact implied by each one), WTF? http://marc.info/?l=linux-kbuild&m=130346037604547&w=2 No one else did check those and said, ACK/NACK so we went in with this initial splitting first. > then it was decided to be split in several level (which I proposed on > Feb 20th, but was originally rejected by Borislav Petkov), Of course, because it made no sense at the time. Sam added it later with his proposal patch. > then, well, some may need to be removed because they are not good for > Linux. have you even tried all those options and come up with concrete suggestions on which options should go in and which shouldn't, and for what reasons? I don't think so. So until you do, I don't care what you have to say. [snip a bunch of bullshit] > Now, the drawback of your comment is that when it will be time to > change the interface, some will object because it will have been > started to be used by third party scripts, and as authors of third > party script, it is a PITA to have to check the kernel version to know > if I should W=1,2,3, or W=123 or if W=3 includes W=1 ... This is exactly why we're trying to get a feeling of this by _running_ it and _then_ _bitching_ about it. And this is for DEVELOPERS only - if they've introduced it in their scripts, then they should be able to fix any changes very easily. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
