@@ -1,44 +1,29 @@
# Maintainer tools
-Useful tools used in daily routines:
+Useful tools for mdadm maintenance:
- [checkpatch](https://docs.kernel.org/dev-tools/checkpatch.html)
- [kup](https://korg.docs.kernel.org/kup.html)
- [Auto-publishing](https://korg.docs.kernel.org/kup.html#auto-publishing-with-git-archive-signer)
- [b4](https://b4.docs.kernel.org/en/latest/)
-# Checklist before applying patch
-
-We don't have CI testing yet, so all those steps must be performed manually:
-- Style check with [checkpatch](https://docs.kernel.org/dev-tools/checkpatch.html):
-
- This is the current code style follows. We are not strict to all rules. It must be run
- by **checkpatch --no-tree**, see README.md.
-
-- [Commit style](https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html):
-
- It doesn't need to be followed as strictly as is in kernel but changes should be logically
- separated. Submitter should care at least to mention "It is used in next patches" if unused
- externs/files are added in patch. We love: *Reported-by:*, *Suggested-by:*, *Fixes:* tags.
-
-- Compilation, ideally on various gcc versions.
-- Mdadm test suite execution.
-- Consider requesting new tests from submitter, especially for new functionalities.
-- Ensure that maintainer *sign-off* is added, before pushing.
-
# Making a release
Assuming that maintainer is certain that release is safe, following steps must be done:
-- Update versions strings in release commit, please refer to previous releases for examples.
+- Make and push release commit:
+ - Update versions strings, refer to previous releases for examples.
+ - Update CHANGELOG.md.
+
+- Create GPG signed tag and push it to both remotes. Use same format as was used previously,
+ prefixed by **mdadm-**, e.g. **mdadm-3.1.2**, **mdadm-4.1**.
-- Create GPG signed tag and push it to repo. Use same format as was used previously, prefixed by
- **mdadm-**, e.g. **mdadm-3.1.2**, **mdadm-4.1**.
+- Run kernel.org
+ [Auto-publishing](https://korg.docs.kernel.org/kup.html#auto-publishing-with-git-archive-signer):
-- [Auto-publishing](https://korg.docs.kernel.org/kup.html#auto-publishing-with-git-archive-signer):
+ Adopt script to our release tag model. When ready, push signed note to kernel.org repository. If
+ it is done correctly, then *(sig)* is added to the package automatically generated by
+ kernel.org automation. There is no need to upload archive manually.
- Adopt script to our release tag model. When ready, push signed note to repository. If it is done
- correctly, then *(sig)* is added to the package automatically generated by kernel.org automation.
- There is no need to upload archive manually.
+- Add release entry on Github.
-- Update CHANGELOG.md.
- Write "ANNOUNCE" mail to linux-raid@kernel.org to notify community.
@@ -20,58 +20,66 @@
**IMPORTANT:** DDF is in **maintenance only** mode. There is no active development around it.
Please do not use it in new solutions.
-# How to Contribute
-
- **mdadm** is hosted on [kernel.org](https://kernel.org/). You can access repository
-[here](https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git).
+# Questions and Support
+
+This Github site is **not** right place to ask if your are looking for:
+- support from Linux Raid Community;
+- support with kernel issues;
+
+This is a the place where development of mdadm application is done. Please, do not use for
+looking for support. You should always ask on [Mailing List](https://lore.kernel.org/linux-raid/).
+
+Please use issues if you have confirmation that issue you are experiencing is related to mdadm
+components:
+- mdadm;
+- mdmon;
+- raid6check;
+- swap_super;
+- test_stripe;
+- systemd services ( see systemd/);
+- udev rules;
+- manual pages (including md.man)
+
+For example:
+- mdadm issues (e.g segfaults, memory leaks, crashes, bad communication with MD driver);
+- feature requests for mdadm;
+- suggestions or minor fixes requested (e.g. better error messages);
+
+Generally, if you are not sure it is better to ask on
+[Mailing List](https://lore.kernel.org/linux-raid/) first.
-It is maintained similarly to kernel, using *mailing list*. Patches must be send through email.
-Please familiarize with general kernel
-[submitting patches](https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html)
-documentation. Formatting, tags and commit message guidelines applies to **mdadm**.
+# How to Contribute
-## Sending patches step-by-step
+Effective immediately [Github](https://github.com/md-raid-utilities/mdadm) is the primary
+location for **mdadm**. Use pull request to contribute.
-To maximize change of patches being taken, follow this instruction when submitting:
+It was originally hosted on [kernel.org](https://kernel.org/). You can access the old repository
+[here](https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git).
-1. Create possibly logically separated commits and generate patches:
+**Patches sent through Mailing List are no longer accepted.**
- Use ``git format-patch --cover-letter --signoff -v <nr>`` to create patches:
- * ``--cover-letter`` can be skipped if it is only one patch;
- * ``--signoff`` adds sign-off tag;
- * ``-v <nr>`` indicates review revision number, sender should increment it before resending.
+**NOTE:** Maintainers may ask you to send RFC to mailing list if the proposed code requires
+consultation with kernel developers.
-2. Check style of every patch with kernel
- [checkpatch](https://docs.kernel.org/dev-tools/checkpatch.html) script:
+Kernel coding style is used. Please familiarize with general kernel
+[submitting patches](https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html)
+documentation. Formatting, tags and commit message guidelines applies to **mdadm**.
- It is important to keep same coding style that is why in **mdadm**
- [kernel coding style](https://www.kernel.org/doc/html/v4.10/process/coding-style.html)
- is preferred. ``checkpath --no-tree <patch_file>`` can be used to verify patches.
- Following checkpatch issues can be ignored:
- - New typedefs.
- - comparing with *True/False*.
- - kernel *MAINTAINERS* file warning.
- - *extern* keyword in headers.
+[Checkpatch](https://docs.kernel.org/dev-tools/checkpatch.html) script is run on
+every patch in pull request so be sure that your commits are not generating
+issues. There are some excludes, so the best is to follow github checkpatch action result.
-3. Send patches using ``git send-mail --to=linux-raid@vger.kernel.org <cover-letter> <patch1> <patch2> (...)``
+Pull Request are closed by `Rebase and Merge` option, so it requires to keep every commit
+meaningful. Kernel style requires that. The review changes must be pushed with **push --force**
+to the chosen branch, then Pull Request will be automatically updated.
-# Maintainers
+# Maintainers of mdadm repository on kernel.org
-It is good practice to add **mdadm maintainers** to recipients for patches:
+If there are differences between github and kernel.org, please contact kernel.org mdadm maintainers:
- Jes Sorensen <jes@trained-monkey.org>;
- Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>;
-Adding **MD maintainers** could be reasonable, especially if patches may affect MD driver:
-
-- Song Liu <song@kernel.org>;
-- Yu Kuai <yukuai3@huawei.com>;
-
-# Reviewers
-
-**mdadm** utility is not part of kernel tree, so there is no certificated *Reviewers* list. Everyone
-can comment on mailing list, last decision (and merging) belongs to maintainers.
-
# Minimal supported kernel version
We do not support kernel versions below **v3.10**. Please be aware that maintainers may remove
Now github will be used for tracking mdadm, adjust README.md. Daily routines will be automated on Github, there is not need to decribe them. Adjust release process, it must be published to both repositories. Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> --- MAINTAINERS.md | 41 ++++++++---------------- README.md | 84 +++++++++++++++++++++++++++----------------------- 2 files changed, 59 insertions(+), 66 deletions(-)