public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Kconfig:  MAINTAINERS file or not?
Date: Tue, 6 May 2014 14:33:03 -0400	[thread overview]
Message-ID: <20140506183303.GY22182@bill-the-cat> (raw)
In-Reply-To: <20140428185854.B2B8.AA925319@jp.panasonic.com>

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>

  parent reply	other threads:[~2014-05-06 18:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-28  9:58 [U-Boot] [RFC] Kconfig: MAINTAINERS file or not? Masahiro Yamada
2014-04-28 20:41 ` Wolfgang Denk
2014-04-30  5:31   ` Masahiro Yamada
2014-04-30 11:52     ` Andreas Bießmann
2014-04-30 16:21       ` Wolfgang Denk
2014-05-06 18:33 ` Tom Rini [this message]
2014-05-06 18:38   ` Stephen Warren
2014-05-06 20:09   ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140506183303.GY22182@bill-the-cat \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox