[U-Boot] [RFC PATCH 3/5] MAINTAINERS.boards: add initial version

[Daniel Schwierzeck]

Dear Wolfgang,

2014-04-20 23:26 GMT+02:00 Wolfgang Denk <wd at denx.de>:
> Dear Daniel Schwierzeck,
>
> In message <1398027454-20399-4-git-send-email-daniel.schwierzeck at gmail.com> you wrote:
>> MAINTAINERS.boards is generated from boards.cfg at
>> commit b149c4c.
>>
>> Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck at gmail.com>
>
> 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.

>
> What you do here means we start distributing the relevant information
> again over a number of different files.  We all know that keeping
> several such files in sync is not only a PITA - it simply does not
> work.

two MAINTAINERS files are an intermediate solution until Kconfig is
finally merged and working. In the meantime you need to refresh the
MAINTAINERS.boards file if boards are added or removed. This task is
easier with two separate MAINTAINERS files. After the Kconfig switch
both MAINTAINERS files should be merged and boards.cfg could be
removed.

>
> Instead of adding such MAINTAINERs files, you should strive to extract
> the relevant information from the existing database (i. e. the
> boards.cfg file - or whatever we decide to have instead of it).
>
> 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).

-- 
- Daniel