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

[Albert ARIBAUD]

Hi Wolfgang,

On Mon, 21 Apr 2014 23:16:48 +0200, Wolfgang Denk <wd at denx.de> wrote:

> Dear Daniel,
> 
> In message <CACUy__UwW=4k0CwcVHhZB8JU-_Fj1cA5TNcCcCyh8E-PF9ELiQ at 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,
-- 
Albert.