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

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

[Masahiro Yamada]

Hi.

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


When I posted the RFC series in March, I put
maintainers info and board status
into defconfig of each board.
But this idea was rejected.

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/

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

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

Any furthur comments about this?


Best Regards
Masahiro Yamada

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

[Wolfgang Denk]

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?

> 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...

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
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offense.                   - E. W. Dijkstra

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

[Masahiro Yamada]

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

[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@denx.de> wrote:
>> 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.

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

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

[Wolfgang Denk]

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

-- 
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

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

[Tom Rini]

On Mon, Apr 28, 2014 at 06:58:55PM +0900, Masahiro Yamada wrote:

> Hi.
> 
> Before I send Kconfig series v2,
> please let me cofirm our approach of maintainers info.
> 
> 
> When I posted the RFC series in March, I put
> maintainers info and board status
> into defconfig of each board.
> But this idea was rejected.
> 
> 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.

So, what do we like, at the high level?  We like being able to leverage
tools and workflows from the linux kernel.  What do we not like?  Lots
of conflicts when merging patches, making things harder for ourselves
than they have to be.

An issue with putting board maintainer into directly into a Kconfig file
is that Kconfig is not awesome arbitrary string contents.  Embedding
maintainer into Kconfig doesn't buy us pre-existing tools and isn't any
easier or harder to copy/paste out of than anything else.

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.

Perhaps a compromise here is to throw lots of MAINTAINERS files around
and whack get_maintainers.pl to loop over all 'MAINTAINERS' files rather
than the single top level one?  That way we can get human understandable
information out easily (who owns board/ti/fooevm/ ? Check
board/ti/fooevm/MAINTAINERS.  New port?  Better include the file in the
patch set) and a small patch to existing tools should handle this multi
file format.

I think this is something that must be within the source tree and not a
de-coupled database somewhere else, which is at least how I recall
reading some of the other suggestions going.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140506/d4d166d6/attachment.pgp>

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

[Stephen Warren]

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.

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

[Wolfgang Denk]

Dear Tom,

In message <20140506183303.GY22182@bill-the-cat> you wrote:
> 
> Perhaps a compromise here is to throw lots of MAINTAINERS files around
> and whack get_maintainers.pl to loop over all 'MAINTAINERS' files rather
> than the single top level one?  That way we can get human understandable
> information out easily (who owns board/ti/fooevm/ ? Check
> board/ti/fooevm/MAINTAINERS.  New port?  Better include the file in the
> patch set) and a small patch to existing tools should handle this multi
> file format.

I think that's an excellent idea.  I'm all for it.  Thanks a lot!

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
Well, the way I see it, logic is only a way of being ignorant by num-
bers.                                 - Terry Pratchett, _Small Gods_