Add a CODEOWNERS file #8670
Add a CODEOWNERS file #8670
Conversation
|
Discussing on the mailing list here: https://externals.io/message/117843 |
|
In theory https://github.com/php/php-src/blob/master/EXTENSIONS is meant to track who's responsible of what |
🤦🏻♂️ Maybe I should have asked before opening this PR and mailing the list |
It might still make sense to use a CODEOWNERS file for the GitHub integration, I suppose it automatically pings the relevant person if a PR is made against those files? |
Yes. It automatically requests a review from them, and they get a notification according to their notification settings. |
|
@ramsey Also, I guess we can automate the PRs labeling for extensions. For example, with actions/labeler action. What do you think? |
Oh, that looks good! |
Tried it now, looks good =) Demo: https://github.com/saundefined/php-src/pull/2 |
|
I like it. That needs less coordination among internals folks than the CODEOWNERS, I think. Open a PR, and we can merge it in. Thanks! |
|
How is the EXTENSIONS file maintained? Where does the end year comes from for maintainers? I'm listed as maintainer of ldap up until 2017, but as far as I know I still am. Also, I'd like to update my surname if possible. |
People should update the file if they want to extend the maintenance year, so it's a very manual and forgetful process |
|
In my opinion, it makes sense to have a CODEOWNERS file (although I don't like the term "code owner"; nobody owns any part of php-src). Contrary to EXTENSIONS, CODEOWNERS has some value, and it might be more realistic to hope that it is kept up to date. In the long run, CODEOWNERS might replace EXTENSIONS (although that should be discussed on the internals mailing list then). |
| /ext/oci8/ @cjbj | ||
| /ext/pdo_oci/ @cjbj |
There was a problem hiding this comment.
I don't think we should list people without their explicit consent (@derickr already said he likes to be informed about ext/date issues), except maybe for those five maintainers in EXTENSIONS which are listed for 2022.
| /ext/oci8/ @cjbj | |
| /ext/pdo_oci/ @cjbj | |
| /ext/com_dotnet/ @cmb69 | |
| /ext/gd/ @cmb69 | |
| /ext/oci8/ @cjbj | |
| /ext/pdo_oci/ @cjbj | |
There was a problem hiding this comment.
You can list me if it makes sense. My affiliation is not a secret !
|
As also just mentioned in R11, I'm also interested in this for |
|
As I've been touching DBA the latest and kinda know how it works, I don't mind being marked for the DBA extension. |
OT, but an additional reason to move ext/imap to PECL soon. |
|
I'm also in favor of this. I don't watch the php-src repository because it is way too noisy. This would allow me to subscribe to the PRs that I may actually be helpful for. |
|
I think to avoid too many discussions the empty file should be added. Anybody who's interested in being associated with a part of PHP can add themselves. |
|
I agree with "someone make the start", as multiple folks expressed their interest, otherwise this is likely not going to go anywhere. |
|
I took the liberty of merging with the changes discussed. Anybody interested can create a PR or add themselves directly to the file. |
|
Thanks, @iluuu1994! |
I'm using this pull request as a point of discussion and to get feedback from the internals community.
As release managers go through open PRs, tagging them with "Waiting on Review," it would be helpful to know from whom we should request reviews, based on the area of the code. One way is to set up a table on the wiki with this information. Another way is to use a GitHub CODEOWNERS file, which takes care of requesting the reviews automatically.
I don't know how feasible it is to maintain a list like this for the PHP project. Ideally, folks would add themselves to the list and self-identify which areas of the code base they want to have automatically request them for reviews.
Apologies to @derickr and @cjbj for using them as examples in this PR. 😄