Re: [PATCH v2 11/11] MAINTAINERS: use a URL for pin-init maintainer's profile entry

[Gary Guo]

On Tue May 5, 2026 at 2:25 PM BST, Mauro Carvalho Chehab wrote:
> This maintainer's entry is not inside documentation nor is
> ReST, preventing Sphinx to create a hyperlink to it.
>
> Change it to point to the already-formatted URL.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx>
> ---
>  MAINTAINERS                   |  2 +-
>  rust/pin-init/CONTRIBUTING.md | 72 -----------------------------------
>  2 files changed, 1 insertion(+), 73 deletions(-)
>  delete mode 100644 rust/pin-init/CONTRIBUTING.md
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8700472b3ae3..b16c8f85d099 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23402,7 +23402,7 @@ S:	Maintained
>  W:	https://rust-for-linux.com/pin-init
>  B:	https://github.com/Rust-for-Linux/pin-init/issues
>  C:	zulip://rust-for-linux.zulipchat.com
> -P:	rust/pin-init/CONTRIBUTING.md
> +P:	https://github.com/Rust-for-Linux/pin-init/blob/main/CONTRIBUTING.md
>  T:	git https://github.com/Rust-for-Linux/linux.git pin-init-next
>  F:	rust/kernel/init.rs
>  F:	rust/pin-init/
> diff --git a/rust/pin-init/CONTRIBUTING.md b/rust/pin-init/CONTRIBUTING.md
> deleted file mode 100644
> index 16c899a7ae0b..000000000000
> --- a/rust/pin-init/CONTRIBUTING.md
> +++ /dev/null

This file is part of the bidirectional source sync.

I think this file is still meaningful in its present location even if not
rendered, so people touching the code would be able to see it and be aware. The
presence of file is more visible than a P entry in the MAINTAINERS file.

That said, if Miguel and/or Benno think it's fine to not have this file, I'm
also okay with it being removed.

Best,
Gary

> @@ -1,72 +0,0 @@
> -# Contributing to `pin-init`
> -
> -Thanks for showing interest in contributing to `pin-init`! This document outlines the guidelines for
> -contributing to `pin-init`.
> -
> -All contributions are double-licensed under Apache 2.0 and MIT. You can find the respective licenses
> -in the `LICENSE-APACHE` and `LICENSE-MIT` files.
> -
> -## Non-Code Contributions
> -
> -### Bug Reports
> -
> -For any type of bug report, please submit an issue using the bug report issue template.
> -
> -If the issue is a soundness issue, please privately report it as a security vulnerability via the
> -GitHub web interface.
> -
> -### Feature Requests
> -
> -If you have any feature requests, please submit an issue using the feature request issue template.
> -compare
> -### Questions and Getting Help
> -
> -You can ask questions in the Discussions page of the GitHub repository. If you're encountering
> -problems or just have questions related to `pin-init` in the Linux kernel, you can also ask your
> -questions in the [Rust-for-Linux Zulip](https://rust-for-linux.zulipchat.com/) or see
> -<https://rust-for-linux.com/contact>.
> -
> -## Contributing Code
> -
> -### Linux Kernel
> -
> -`pin-init` is used by the Linux kernel and all commits are synchronized to it. For this reason, the
> -same requirements for commits apply to `pin-init`. See [the kernel's documentation] for details. The
> -rest of this document will also cover some of the rules listed there and additional ones.
> -
> -[the kernel's documentation]: https://docs.kernel.org/process/submitting-patches.html
> -
> -Contributions to `pin-init` ideally go through the [GitHub repository], because that repository runs
> -a CI with lots of tests not present in the kernel. However, patches are also accepted (though not
> -preferred). Do note that there are some files that are only present in the GitHub repository such as
> -tests, licenses and cargo related files. Making changes to them can only happen via GitHub.
> -
> -[GitHub repository]: https://github.com/Rust-for-Linux/pin-init
> -
> -### Commit Style
> -
> -Everything must compile without errors or warnings and all tests must pass after **every commit**.
> -This is important for bisection and also required by the kernel.
> -
> -Each commit should be a single, logically cohesive change. Of course it's best to keep the changes
> -small and digestible, but logically linked changes should be made in the same commit. For example,
> -when fixing typos, create a single commit that fixes all of them instead of one commit per typo.
> -
> -Commits must have a meaningful commit title. Commits with changes to files in the `internal`
> -directory should have a title prefixed with `internal:`. The commit message should explain the
> -change and its rationale. You also have to add your `Signed-off-by` tag, see [Developer's
> -Certificate of Origin]. This has to be done for both mailing list submissions as well as GitHub
> -submissions.
> -
> -[Developer's Certificate of Origin]: https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> -
> -Any changes made to public APIs must be documented not only in the commit message, but also in the
> -`CHANGELOG.md` file. This is especially important for breaking changes, as those warrant a major
> -version bump.
> -
> -If you make changes to the top-level crate documentation, you also need to update the `README.md`
> -via `cargo rdme`.
> -
> -Some of these rules can be ignored if the change is done solely to files that are not present in the
> -kernel version of this library. Those files are documented in the `sync-kernel.sh` script at the
> -very bottom in the `--exclude` flag given to the `git am` command.