From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 22 Apr 2014 08:42:40 +0200 Subject: [U-Boot] [RFC PATCH 3/5] MAINTAINERS.boards: add initial version In-Reply-To: <20140421211648.4ABD33803C8@gemini.denx.de> References: <1398027454-20399-1-git-send-email-daniel.schwierzeck@gmail.com> <1398027454-20399-4-git-send-email-daniel.schwierzeck@gmail.com> <20140420212645.797AD3803FB@gemini.denx.de> <20140421211648.4ABD33803C8@gemini.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, On Mon, 21 Apr 2014 23:16:48 +0200, Wolfgang Denk wrote: > Dear Daniel, > > In message you wrote: > > > > > I understand your intentions, but I have to admit that I seriously > > > dislike this approach. It has been quite a long way to come up with > > > boards.cfg, which would attempt to colect all relevant information for > > > a board in a single database. In my opinion, this is still the right > > > way we should go: maintain all related information in a single place. > > > > the main intention is to support introduction of Kconfig, which > > eventually obsoletes the mkconfig script. This, in turn obsoletes the > > information about arch, CPU/SOC, vendor, special config options in > > boards.cfg. Thus boards.cfg would only contain infos about status, > > name and mail address of board maintainers. Furthermore we still don't > > have infos about custodians and their trees in boards.cfg. As you > > stated in your other response the wiki page isn't a reliable source. > > Actually we also have some quasi-official maintainers without > > dedicated custodian trees (e.g. sandbox, driver model). Those > > maintainers are currently not recorded at all. So it makes sense to > > collect all those informations in one single MAINTAINERS file. Finally > > all contributors would have more comfort in building the relevant cc > > list for their patches. > > I fully understand your intentions, and I agree with your comments > about information missing in boards.cfg. I will also fully agree to > any statement that boards.cfg is not a perfect database for the kind > of information we would like to collect. > > But I still disagree with the approach taken here. Yes, I know that > MAINTAINERS is just following the Linux kernel example. But I > believe devoutly that we should strive to collect all relevant data in > a single database (whichever form this may have) instead of spreading > it over a number of different files. As is, we have to add just a > single line to boards.cfg (or, in a more general view, an atomic entry > to a database) to add a new board. Introducing MAINTAINERS will > scatter information around, and it will become a permanent nightmare > to keep information consistent: you will have to touch several files > and always have to keep them in sync - which has never worked well. > > > > In any case, scattering such data all over the place is a bad thing to > > > do. > > > > IMHO the goal should be to have one MAINTAINERS file for maintainer > > infos and board-specific Kconfig files for all board config stuff > > (incl. include/configs/$boardname.h). > > This sounds fine, but I feel the current implementation is a step > backwards. It makes things worse than better. [And I have to admit > that I'm not fully convinced that the end goal you pattern here would > actually work as you describe it.] > > I wonder if I'm alone with my concerns? Anybody else with comments? I can hardly disagree with you about ( boards.cfg + MAINTAINERS.* ) being awkward to maintain, since I'm the one who merged them into a single boards.cfg file. :) Can'we have the maintainer(s) be part of the board config file from the start, like a required (but possible non-editable) configuration item, something like "CONFIG_MAINTAINER_EMAIL"? This would, at least, keep all information for a single board in a single place. > Best regards, > > Wolfgang Denk Amicalement, -- Albert.