Process: replacing CODEOWNERS with MAINTAINERS #38725
Comments
|
new syntax proposal for the MAINTAINER file |
|
Process WG minutes:
|
|
@abrodkin @evgeniy-paltsev @ruuddw - we need to copy ARC-related entries from CODEOWNERS to MAINTAINERS - as I remember we didn't maintain MAINTAINERS file for us and didn't add proper info to it. |
|
Process WG minutes:
|
|
Process WG minutes:
|
|
So if I understand what manifest.py#L425 is doing, this is not what I was asking for. I'm looking for something that would provide a class and functions that scripts that want to parse the MAINTAINERs files could be build around. See: zephyr/scripts/ci/get_twister_opt.py Line 128 in 9cb94df |
OK, yeah, that is also supported in the same file, just lower down (in the Manifest class). So you're basically asking for a library with generic parsing and validation support that is reusable elsewhere, right? |
|
@galak when we discussed the various files, the unification and reuse of code idea was primarily around the way we parse the wildcards for paths in CODEOWNERS, MAINTAINERS.yml and tags.yaml. The yaml syntax can vary and I do not see how we can verify the syntax in a generic way. |
|
Process WG minutes:
|
|
Process WG:
|
|
@mbolivar-nordic lets put this on the agenda tomorrow, there are things blocking this that need to be discussed. |
So, the boards is going to be an easy one, we just add maintainers list per board in the board yaml file we already have, a quick PoC shows we can even get those populated from the existing CODEOWNERs file and then integrate it in the script that does the labeling and adding reviewers. The challenge is how to deal with everything else, like drivers. We can solve multiple problems with one solution I guess, the most extreme approach would be to have metadata files per subsystem where we can list all the information needed about instances, their maintainers, how they are tested and how they relate to other areas in Zephyr, so for example for I2C, this could look like this: Based on the information above and without the need for too much parse magic we can:
The main challenge of the above is how we get there and how we continue to maintain those files and keep them in sync, I guess CI can enforce this in different way, similar to how enforce this with CODEOWNER now, if you add a file or a new driver that is not part of this "database", you will be asked to add it.... |
There is another way that does rely on DTS that I think would be better than "platforms": devicetree compatibles. Instead of: I suggest using: I.e. a list of compatibles that this driver supports. I also think there should be a documented top-level kconfig option for enabling the driver. |
|
Process WG:
|
@nashif , how could we find the mapping from given file to dts defines? using scripts to check the fild compatbile defines? but it is only existing in .c file, what if we change the .h file? or common file? |
a question for @mbolivar-nordic I guess |
@mbolivar-nordic I guess you don't think about dealing with dts at each CI run (need to compile all dts for each target and take into account tests/samples in which targets are modified by overlays ...). |
I'm planning on picking this back up at next week's process meeting so I am looking back at this. I'm sorry @hakehuang , but I don't understand your question. Could you please give me some example?
I don't know what you mean here either, @erwango. The example from @nashif is a list of drivers. Surely the compatibles that a driver handles do not change with overlays being applied by tests/samples, so I don't get what you're asking about. |
my question is how could we find the target application when only .h source is changed? or subsystem code is changed, which does not mapping to all supporting platform for given test application. |
|
.h source where? Sorry, could you please give me an example of some real files in zephyr? |
for example if I modify the 'zephyr\subsys\net\l2\ethernet\gptp\gptp_md.h', all impacted platfroms shall be built against, and how can I get the mapping relationship? |
This is part of the road towards replacing CODEOWNERS with MAINTAINERS (tracked in the process working group as zephyrproject-rtos#38725). As part of that work, we wanted to have a way to track the maintainers of each west project (entry in west.yml) by name of project. This is an initial attempt at that, based mostly on my personal knowledge, the git logs, and some rough guesswork. I fully expect omissions and errors, but it should be enough to get us started, with fixes to follow incrementally from the people who know their individual areas better than I do. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is part of the road towards replacing CODEOWNERS with MAINTAINERS (tracked in the process working group as #38725). As part of that work, we wanted to have a way to track the maintainers of each west project (entry in west.yml) by name of project. This is an initial attempt at that, based mostly on my personal knowledge, the git logs, and some rough guesswork. I fully expect omissions and errors, but it should be enough to get us started, with fixes to follow incrementally from the people who know their individual areas better than I do. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
|
Process WG:
|
|
@nashif Just wanted to call out a specific use case where CODEOWNERS falls short for boards: the
In the case of Zephyr, It seems that contributors who are not members of Zephyr on GitHub won't be added to the review list for files they are the code owner of. |
|
Moving status to on hold since it's on my plate but I haven't touched it yet to add I2C driver maintainers. Will move back to In Progress when I have a PR. |
|
#46373 and #46380 implemented a script and workflow to automatically assign the reviewers, assignee and labels based on the content of the MAINTAINERS.yml. With that, we are now a step closer to replacing CODEOWNERS with MAINTAINERS.yml; we just need to make sure that the MAINTAINERS.yml is not missing any entries from the CODEOWNERS. |
|
Process WG:
We'll put this on hold until next week's meeting at the latest, or whenever @nashif has a chance to comment either on Discord or in this issue. |
|
Process WG:
|
|
Process WG: revisit next week |
What I find missing in the giant linux/MAINTAINERS approach is... a bird's eye view. No way to zoom in and out. Searching is impractical when trying to match a path: which subdir to look for? linux/MAINTAINERS itself asks to try subdirs one by one. I suspect linux/MAINTAINERS a write-only database that is never read; readers always use the script. Good luck trying to do this sort of filtering with a single giant file: |
|
Process WG: moved back to on hold; @stephanosio is busy |
|
Will it be possible to unsubscribe from some pull requests? Not sure what the current status is now but "zephyrbot" keeps re-adding you after every force-push. I guess because a force-push can include new changed files but that's not the most common case. |
|
I've run into a situation where an SOC/Board was contributed to Zephyr from a different business unit in NXP. Now that person wants to be the maintainer of the relevant files and be automatically pulled into PR reviews if those files are touched. He initially had updated the codeowners file to associate with the files but that apparently doesn't completely work unless he gets put into the MAINTAINERS file. I'm going to do that but now I'm getting too many collaborators at the top level. Which seems to imply needing some hierarchy in the MAINTAINERS file. |
zephyrbot
added
the
Needs review
This issue tracks replacing the CODEOWNERS file with the MAINTAINERS file.
The CODEOWNERS file and MAINTAINERS files contain duplicate information. The labeler.yml file would also be obsoleted by using a MAINTAINERS file in combination with a script from @nashif which adds labels as well.
Issues to sort out and current status:
How do we handle "non-maintainer" code owners?
Issue summary: CODEOWNERS and MAINTAINERS serve different but related purposes today, and many people who belong in CODEOWNERS do not belong in MAINTAINERS as it is currently defined.
Status
Current thinking is to define a new "sub-areas" concept, that lets us split up areas large enough to deserve a maintainer -- like "the I2C subsystem" -- into smaller components -- like "the nRF TWIM I2C driver".
We want to extend the MAINTAINERS YAML schema to allow us to define sub-areas and their "owners". Details are still TBD. @stephanosio has agreed to work on this syntax.
Details
One file, or many?
Issue summary: do we want to continue to put everything in a single MAINTAINERS file, or do we want to have various files throughout the tree that let us distribute sub-area owners into related directories?
For example, should we have the nRF TWIM driver owner in MAINTAINERS, or in a new drivers/i2c/SUB-MAINTAINERS file (exact name of the "sub-area" files is up for bikeshedding).
Current status The current consensus of the group is towards a single MAINTAINERS file with a new "sub-areas" syntax (TBD) for tracking individual components of a subsystem or area and their owners. Multiple "sub-MAINTAINERS" files throughout the tree were proposed but a supermajority of participants did not want to go this way, mainly because it seemed easier to search through a single file than many.
How to do the move?
Issue summary: Delete CODEOWNERS and move forward, or audit CODEOWNERS to make sure we have coverage in MAINTAINERS?
Current status: delete and move forward, but then how do we ensure that
MAINTAINERS.ymlcontains all collaborators from theCODEOWNERSfile?Details
What other metadata do we want?
Issue summary having a YAML file for describing components like individual drivers opens up opportunities to maintain additional useful metadata about those components. What do we want to add here?
Current status TBD, but some ideas are:
The text was updated successfully, but these errors were encountered: