[U-Boot] [RFC] [PATCH 0/5] Refactor MAINTAINERS file

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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,
-- 
Albert.