Dear Daniel,
In message <CACUy__UwW=4k0cwcvhhzb8ju-_fj1ca5tnccccyh8e-pf9e...@mail.gmail.com>
you wrote:
>
> > I understand your intentions, but I have to admit that I seriously
> > dislike this approach. It has been quite a long way to come up with
> > boards.cfg, which would attempt to colect all relevant information for
> > a board in a single database. In my opinion, this is still the right
> > way we should go: maintain all related information in a single place.
>
> the main intention is to support introduction of Kconfig, which
> eventually obsoletes the mkconfig script. This, in turn obsoletes the
> information about arch, CPU/SOC, vendor, special config options in
> boards.cfg. Thus boards.cfg would only contain infos about status,
> name and mail address of board maintainers. Furthermore we still don't
> have infos about custodians and their trees in boards.cfg. As you
> stated in your other response the wiki page isn't a reliable source.
> Actually we also have some quasi-official maintainers without
> dedicated custodian trees (e.g. sandbox, driver model). Those
> maintainers are currently not recorded at all. So it makes sense to
> collect all those informations in one single MAINTAINERS file. Finally
> all contributors would have more comfort in building the relevant cc
> list for their patches.
I fully understand your intentions, and I agree with your comments
about information missing in boards.cfg. I will also fully agree to
any statement that boards.cfg is not a perfect database for the kind
of information we would like to collect.
But I still disagree with the approach taken here. Yes, I know that
MAINTAINERS is just following the Linux kernel example. But I
believe devoutly that we should strive to collect all relevant data in
a single database (whichever form this may have) instead of spreading
it over a number of different files. As is, we have to add just a
single line to boards.cfg (or, in a more general view, an atomic entry
to a database) to add a new board. Introducing MAINTAINERS will
scatter information around, and it will become a permanent nightmare
to keep information consistent: you will have to touch several files
and always have to keep them in sync - which has never worked well.
> > In any case, scattering such data all over the place is a bad thing to
> > do.
>
> IMHO the goal should be to have one MAINTAINERS file for maintainer
> infos and board-specific Kconfig files for all board config stuff
> (incl. include/configs/$boardname.h).
This sounds fine, but I feel the current implementation is a step
backwards. It makes things worse than better. [And I have to admit
that I'm not fully convinced that the end goal you pattern here would
actually work as you describe it.]
I wonder if I'm alone with my concerns? Anybody else with comments?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Defaults are wonderful, just like fire.
- Larry Wall in <1996mar6.004121.27...@netlabs.com>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
