Dear Andreas,
In message 5360E3ED.9090708@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