Hi Wolfgang,
On Wed, 24 Jul 2013 06:34:30 +0200, Wolfgang Denk wd@denx.de wrote:
Dear Albert,
In message 1374611299-16836-1-git-send-email-albert.u.boot@aribaud.net you wrote:
This patch series aims at refactoring MAINTAINERS into an easily processable file.
Thanks! Much appreciated.
There are not actually five changes as such; the first four patches are step-by-step cleaning so that the last patch can be created essentially by running an AWK script on MAINTAINERS.
Hm, I wonder if we shouldadd (back) a column providing information about the SoC type? When searching for - for example - maintainers for all i.MX6 boards it's not really helpful to only have a huge list of "ARM" boards.
OK, you can argument that we can extract this information using "MAKEALL -l", but then we could also omit the architecture column in the MAINTAINERS file.
Alternatively, we could drop the MAINTAINERS file and just add the status and name/mail address columns to the boards.cfg file. I agree that this would become even more unreadabe, but then we'd have all information in a single place. [Merging MAINTAINERS into boards.cfg could be done automatically using your last file format as input.]
What do you think?
Thanks for your coments. I'd thought about this too but I feared the change would be too drastic. Happy to see you're considering it.
Merging is feasible. The major change to my current RFC would be that instead of multiple lines for a board with multiple maintainers (which build processes based on boards.cfg would have trouble dealing with), I would keep a single line listing all maintainers' e-mail addresses, probably separated with commas and no spaces, for consistency with the options field and to keep script-based parsing easier. Empty options fields would probably have to be replaced with something like '-', which is already being used in boards.cfg, e.g. for Vendor, so that Options and Maintainers fields are easily distinguished.
Of course, active boards boards should be put at the start of the file and orphans at the end, so that scripts only meant for active boards could detect when reaching the first orphan board and stop processing boards.cfg as early as possible.
While we are on the sorting topic, the canonic sorting order for boards.cfg is, as per its heading comments, "ARCH, CPU, SoC, Vendor, Target" while the current display order has Target first, and Vendor and SoC the other way around. We can take this occasion to fix and homogenize the sorting and display orders. I would suggest adopting a 'progressive refinement' sort and display order:
Status, ARCH, CPU, SoC, Vendor, Board name, Target, Options, Maintainers
This has the benefit that, assuming the tabular column format is kept, a simple sort command should be enough to keep the entries in order, rather than the convoluted 'sort -bdf -k2,2 -k3,3 -k6,6 -k5,5 -k1,1' currently needed.
Another benefit is that this display order groups together 'technical' fields (ARCH, CPU, and SoC), 'commercial' fields (Vendor and Board name), and 'U-Boot' fields (Target, Options and Maintainers). One could argue that by my own logic Status should be in the last group; but Status is an important sort key for scripts that only want to process active boards as I described above, and I want to remain able to simply 'sort' boards.cfg, hence the trade-off.
Of course, these changes to the boards.cfg field order would have to reflect on the scripts that use it. I can take care of uses within the U-boot repo, but whatever is out there in the wild will have to cope by itself.
Best regards,
Wolfgang Denk
Amicalement,