Hi Wolfgang,

On Mon, 28 Apr 2014 22:41:07 +0200 Wolfgang Denk wd@denx.de wrote:

Dear Masahiro,

In message 20140428185854.B2B8.AA925319@jp.panasonic.com you wrote:

...

Before I send Kconfig series v2, please let me cofirm our approach of maintainers info.

Thanks for all your patience when dealing with all these apparently simple things that nevertheless take so much time and nerves to decide.

...

Instead, MAINTAINERS file as in Linux Kernel was proposed. (And the patch series by Daniel is already on Patchwork.) http://patchwork.ozlabs.org/patch/340546/ But Wolfgang (and Albert) disagreed with it.

In Kconfig v1 series, I put maintainers info and board status in board/*/*/Kconfig as non-user-editable settings: http://patchwork.ozlabs.org/patch/342089/

I find myself in the difficult situation that I'm not really happy with either of these approaches, but then I don't have any better solution to suggest. I think I find the board/*/*/Kconfig a bit better.

...

But I am not sure if this is a good idea. (At least, it is dirty.)

Could you please explain why you think so?

CONFIG_BOARD_MAINTAINER is not referenced from anywhere. It is written just for a record. It's nothing more than a comment.

In my option, a plain text like boards.cfg or MAINTAINERS might be more suitable for that kind of information.

Even if somebody adds a new board and makes a typo error, for example, "config BOARD_MAINTANER", no error is reported. This is a mistake hard to find.

Another reason why I think a platin text is more suitable is that some maintainers' name include quoatations and they must be escaped.

Please notice this entry in board/dave/PPChameleonEVB/Kconfig:

config BOARD_MAINTAINER string default "Andrea "llandre" Marson andrea.marson@dave-tech.it"

Does this look strange? But the back-slashes before quotations are necessary to aviod Kconfig error.

...

In v2, I will drop maintainers info and board status from Kconfig and leave them to Daniel's patch.

Hm... :-(

I hope others will provide more feedback - I'd be seriously unhappy if this decision was based only on gut feelings like mine...

Yes. We must make a decision. But this decision is difficult.

Best Regards Masahiro Yamada

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

On 05/06/2014 12:33 PM, Tom Rini wrote: ...

An issue with a single top-level MAINTAINERS file is that we'll get conflicts galore. What a MAINTAINERS file would give us is get_maintainers.pl from the kernel which can be helpful.

The conflicts we'll get are likely to be quite trivial to resolve though.

All changes to a particular entry should go through the subsystem tree that the entry applies to (e.g. only the USB tree should change a top-level USB entry, only an architecture or SoC tree should change an entry for drivers for that architecture/SoC, etc.)

As such, it's pretty unlikely there will be many conflicts at all except a few trivial context changes, or some add/add, add/delete conflicts of adjacent blocks. I haven't see Linus complaining about issues merging MAINTAINERS at all, and he'd complain if it was a problem.

Or, you could just say "all MAINTAINERS changes go through u-boot.git directly". Then, there will be zero conflicts.