On Fri, 7 Nov 2008, Sergei Shtylyov wrote: > > If you would like me to move the Kconfig patch to the end, I can do that. > > That way you wouldn't have any breakage for octeon if you were to only apply > > a subset of the patches. Other than that, there are currently no plans to > > restructure this patch set to try to maintain rigorous define before use > > ordering. > > Maybe it's just me, but IMHO first using the macro and then, 15 patches > after that, having a patch that just adds that macro, is going against the > common sense... Hmm, I smell the set has been created by splitting a large diff that adds this new platform in one go. If so, I have been through such things in the past and I understand how painful and difficult it may be and how much effort it requires -- the more the bigger the change. I think common sense should apply here. I agree this is not a very good practice. But what would be the gain to justify all this extra effort needed to verify there are no forward references within the set? I gather there would be no gain at all except from purity. Well, I am a well-known purist as well, but you have to draw a line somewhere. On the other hand the idea to only add the Kconfig option at the end so that none of the changes are enabled in the limbo state is in my opinion a very good one. For example some people use random config generators -- I am not sure if for the MIPS port too, but I cannot exclude that either -- so I think it would be good to make sure a broken configuration is not created accidentally by one of such automata. Please consider this option seriously, David. Maciej
