[U-Boot] [PATCH 1/2] common: mark commands as default to match "config_cmd_default.h"

[Alexey Brodkin]

Hi MAsahiro-san,

On Fri, 2015-01-16 at 03:36 +0900, Masahiro YAMADA wrote:
> Weird. I can access the link.
> 
> The subject is
>  [RFC] How to move lots of CONFIGs from header files to Kconfig
> 
> 
> Another URL is
> http://lists.denx.de/pipermail/u-boot/2014-October/193117.html

Thanks a lot! Now I was able to read your message. And it looks like I
was proposing the same options (1) and (2) :-)

>  work as well.
> > So my point is:
> >  1) anybody may do updates to Kconfig like add more U-Boot commands,
> > some settings (CONFIG_SYS_xxx)
> 
> Yes, U-Boot is an open source project.
> Anybody can contribute and it is very appreciated.

Here I implicitly meant "anybody" = "either you or me" because we're
both interested in that change to be done and sooner is better :-)

> >  2) board maintainers are responsible for updates in defconfigs and
> > corresponding headers in "include/configs/"
> 
> Yes. I expect this, but some board maintainers might not like to do it
> for some reason.
> ( too busy, no interest , etc.)

That's understood. But probably we may move forward with both
implementations: Kconfig & config headers. 

I really hate to introduce breakages for people so if co-existence of
config headers with Kconfig is a matter of few "ifdefs" (an example is
my patch for default commands) then why not?

In the end once inactive maintainer returns back (for example it was
right the case for me recently) he most probably will spend some time on
switching to Kconfig just because defconfig way is so much cleaner
compared to headers.

> At some point, we need to convert globally, I think.

Completely agree, and if we're done with well-maintained arches and
boards "complete switch" will be as easy as:
 1. Removal of more stale boards
 2. Auto-conversion of headers to defconfigs with automated script

For sure (2) will introduce unexpected behavior for some boards. Then if
people start complaining real maintainer or we will incrementally fix
things.

> >  3) that would be helpful if at (1) board maintainers are notified via
> > direct emails on the change that has been done
> 
> Yes, good idea.

That's important because not everybody follows mailing list closely
especially if their development focus is temporary switched to other
projects.

> >> > I personally keep away from any global changes until
> >> > non-generic boards are dumped.
> >> >
> >> > As Tom said in the following mail,
> >> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html
> >> > we are going to remove lots of boards.
> >> >
> >> > I do not want to make extra efforts on non-generic boards.
> >
> > That makes sense but why don't we start implementation of changes in
> > good boards we know already converted to "generic"? There're even entire
> > arches that switched to "generic boards".
> 
> Yes, we can start with well-maintained boards.

This is important because "release early, release often". In the very
beginning of Kconfig way we'll do many non-optimal or even plain wrong
decisions (probably even intentionally just because at that point it
could be the best decision we see). And then by the time of
"global/complete switch" to Kconfig most of thins will be implemented
properly and most of issues fixed.

-Alexey