Hi Wolfgang,
On Mon, 21 Apr 2014 23:16:48 +0200, Wolfgang Denk wd@denx.de wrote:
Dear Daniel,
In message CACUy__UwW=4k0CwcVHhZB8JU-_Fj1cA5TNcCcCyh8E-PF9ELiQ@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?
I can hardly disagree with you about ( boards.cfg + MAINTAINERS.* ) being awkward to maintain, since I'm the one who merged them into a single boards.cfg file. :)
Can'we have the maintainer(s) be part of the board config file from the start, like a required (but possible non-editable) configuration item, something like "CONFIG_MAINTAINER_EMAIL"?
This would, at least, keep all information for a single board in a single place.
Best regards,
Wolfgang Denk
Amicalement,