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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot