Hi Christian

Sorry I'm coming to this late but I have some feedback on your proposal:

 

* I agree on the need for a TF-M maintainers file and following the Linux style. TF-A already does this and might be worth copying.

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about/maintainers.rst

 

* If the TF-A style doesn't work for TF-M then it would be good to figure out why and align both projects.

 

* The TF-A "Main maintainers" are the ones with +2/merge rights. Other listed maintainers (i.e. sub-maintainers) are there just to show who to chase for code review; they only have +1 rights like everyone else. For TF-M, I'm open to the idea of giving all listed maintainers +2 rights as long as this doesn't give them merge rights! However, I'm sceptical on the value of this since the person merging will still need to check who has given +1/+2 before merging. Also, this could grow to a long list of people if TF-A is anything to go by, which could easily lead to abuse/confusion.

 

* Regarding expanding the list of those with merge (or "Main maintainer") rights, I agree with Kumar that this should be a meritocracy. However, I don't think the TSC need to be involved in the first instance; this can be simply approved by existing "Main maintainers" via the public lists. I think the TSC only needs to get involved if someone wants to be a "Main maintainer" and the existing "Main maintainers" don't approve, or if someone objects to a new "Main maintainer" being added. Escalation to the board should be rare.

 

* I don't think TF members should automatically get "Main maintainer" rights, although some TF members may be ready to be "Main maintainers" now (if approved by the existing TF-M "Main maintainers").

 

Regards

Dan.