[U-Boot] [RFC] Kconfig: MAINTAINERS file or not?

[Wolfgang Denk]

Dear Andreas,

In message <5360E3ED.9090708 at gmail.com> you wrote:
> 
> But I also think we need something like the MAINTAINERS approach sent by
> Daniel. It maybe won't scale for boards but I think it is a better
> solution than the Wiki page. It allows fine grained allocation of
> responsibility for the code. Another advantage over the wiki approach is
> that one can get the information directly from the code, even off-line.

We should be careful not to mix things here.

The wiki page documentes which git repositories exist, and who is the
responsible custodian with the permissions to pull into these repos.

Yes, this is also related to code maintenance, but we intentionally
avaoided the name "maintainers" in this context for a reason.  There
is some overlap, but the custodians and the code maintainers are two
different sets of people.

> So why do we need the board database at all? We want to know who owns a
> specific board for testing.

This is one of many use cases.  Other possibilities are:

- find / compile all boards of a specific architecture
- find / compile all boards of a specific SoC type
- find / compile all boards of a specific vendor
- find / compile all boards owned by some specific person
- find / compile all configurations of a specific board
etc.

> So again, why do we need the board database? Couldn't we just ask git
> who was involved in a board and ask those people when problems arise?

No, this is not practical.  Check any orphaned board.  You will find
tons of edits of the board code over the years, where people adapted
the code to global reworks, fixed coding style issues, etc.  It is
usually extremely difficult and often impossible to find out who the
actual "responsible" for a board is / was.

> The database is currently also used for finding a board to compile. This

Note that the "finding" we can do so far is not restricted to "find to
compile"; it also offers "find to list", and offers a number of pretty
useful selection options (see "./MAKEALL -h" for a list and some
examples).

> will anyway be replaced by Kconfig. So for the 'which code compile'
> thing we need more a strict convention than a database.

I definitely do ot want to lose the existing functionality.  It has
been way too useful in the past to lightly abandon it.

> The question is, do we really need that database?

No, we don't.  But only if we find another implementation that is 1)
easy to maintain; 2) easy to keep consistent; and 3) flexible enough
to support the existing use cases.

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: wd at denx.de
"It's when they say 2 + 2 = 5 that I begin to argue."    - Eric Pepke