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

[Andreas Bießmann]

Hi all,

On 04/30/2014 07:31 AM, Masahiro Yamada wrote:
> On Mon, 28 Apr 2014 22:41:07 +0200
> Wolfgang Denk <wd at denx.de> wrote:
>> In message <20140428185854.B2B8.AA925319 at 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.

in general this sounds good to me. I also think placing the information
'who owns that board' should be tightly coupled to the board code, if we
store that information at all.

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.

I thought a bit about board database and directory tree arrangement and
wanted to present that approach here. While writing it I hit on the main
problem.

So why do we need the board database at all? We want to know who owns a
specific board for testing.
But there is no procedure to check these boards frequently. We had this
discussion before. The solution was AFAIR a database with
Active/Orphaned switch. Orphaned boards should go to scrapyard when
problems arise.

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?

The database is currently also used for finding a board to compile. This
will anyway be replaced by Kconfig. So for the 'which code compile'
thing we need more a strict convention than a database.

The question is, do we really need that database?

Best regards

Andreas Bießmann