On 2012-04-16 7:29 PM, Peter Laufenberg wrote: > You seem to have a very stance; is this even up for discusion or > will it come down to a principled "over my dead body"? :) I'm still waiting for somebody to demonstrate to me that this is actually useful in a *meaningful* way. So far (to me) the upside seems to be purely cosmetic, whereas I consider the downside relevant and real enough to be opposed to this change.
>>On 2012-04-14 9:37 PM, Jeroen van Bemmel wrote: >>> The Linux kernel version is an important configuration aspect still >>> missing from menuconfig. It should be possible to have the full config >>> in a single .config file; Makefiles are the wrong place for setting this >>> parameter. >>> I agree it would be uncommon to change this, that's why it is a >>> developer option. >>Since this is meant for developers, it really does not need to be in >>.config. Editing a makefile is easy for a developer. Adding a config >>option simply adds yet another place where the version number has to be >>maintained, without making things significantly easier. > > Compiling anything is for developers. Whatever helps is a Good Thing; nobody > expects the holy grail. It's only a good thing if the benefit outweighs the cost, and I'm not sure this is the case here. >>> I think we're missing a process for updating the kernel version; can't >>> just edit the Makefile and hope all images keep working. Device profiles >>> could be a way to at least coordinate testing of a specific version for >>> a specific device. It does not set the kernel version, but the suggested >>> version for testing >>Most targets have a generic profile that works for all devices anyway. >>For people that do not follow all changes in a target it would come as a >>nasty surprise when simply switching profiles suddenly nukes the kernel >>tree and uses a different version. >> >>There is another annoying issue with having too many config options: >>Random users playing with developer-only options, then complaining about >>breakage later without mentioning that they changed some options that >>they had no clue about. > > Talking of "developers vs clueless users" isn't helpful. Good > developers constantly acquire new skills -- clueless before, experienced > after -- and there's plenty of bad developers writing crappy kernel code > without a config. Changing a Makefile isn't a high entry barrier at all, especially not for a developer. > If you mean those "time-consuming, hopeless, lazy, RTFD-immune, > wannabe developers", I suggest adding a Trac entry like for any other > problem requiring a solution, starting with a detailed rational > (unemotional) description. Maybe a mandatory web form that generates a > sanity report before considering complaints would filter out most of > this human-to-human spam. The main problem is that recognizing whether the user did something stupid is not something that can be automated. Users changing random options and then not mentioning that in reports is a *real* problem, which has already wasted enough of my time and other developers' time as well. And your 'mandatory web form' option isn't really helping either. Who's going to make such a form and make it foolproof as well? I really don't think it can be done in a reliable way. And even if it could be done properly, that just takes us right back to the costs vs benefits discussion. Is all of this effort worth it for just a minor usability improvement for testing new kernels? I don't think so... >>We've seen this with compiler options, libc >>options, deselecting packages, etc. I really don't want to add kernel >>versions to the mix, especially with so little potential gain from >>adding something like this. > > I agree that just throwing in more options is bad, but so is > obscuring parts of the build, reserved to an elite developer caste. It's not about reserving it to an elite developer caste. Changing a Makefile is inherently simple, and I consider it a required skill for anybody who wants to be a developer :) - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
