Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
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
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
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: w...@denx.de Well, the way I see it, logic is only a way of being ignorant by num- bers. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
Hi all, On 04/30/2014 07:31 AM, Masahiro Yamada wrote: On Mon, 28 Apr 2014 22:41:07 +0200 Wolfgang Denk w...@denx.de wrote: In message 20140428185854.b2b8.aa925...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
Dear Andreas, In message 5360e3ed.9090...@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: w...@denx.de It's when they say 2 + 2 = 5 that I begin to argue.- Eric Pepke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
Hi Wolfgang, On Mon, 28 Apr 2014 22:41:07 +0200 Wolfgang Denk w...@denx.de wrote: Dear Masahiro, In message 20140428185854.b2b8.aa925...@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.mar...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
Dear Masahiro, In message 20140428185854.b2b8.aa925...@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: w...@denx.de The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. - E. W. Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
