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