[PATCH 0/1] Move mdadm development to Github

[PATCH 0/1] Move mdadm development to Github

[Mariusz Tkaczyk]

Thanks to Song and Paul, we created organization for md-raid on Github.
This is a perfect place to maintain mdadm. I would like announce moving
mdadm development to Github.

It is already forked, feel free to explore:
https://github.com/md-raid-utilities/mdadm

Github is powerful and it has well integrated CI. On the repo, you can
already find a pull request which will add compilation and code style
tests (Thanks to Kinga!).
This is MORE than we have now so I believe that with the change mdadm
stability and code quality will be increased. The participating method
will be simplified, it is really easy to create pull request. Also,
anyone can fork repo with base tests included and properly configured.

Note that Song and Paul are working on a per patch CI system using GitHub
Actions and a dedicated rack of servers to enable fast container, VM and
bare metal testing for both mdraid and mdadm. Having mdadm on GitHub will
help with that integration.

As a result of moving to GitHub, we will no longer be using mailing list
to propose patches, we will be using GitHub Pull Requests (PRs). As the
community adjusts to using PRs I will be setting up auto-notification
for those who attempt to use email for patches to let them know that we
now use PRs.  I will also setup GitHub to send email to the mailing list
on each new PR so that everyone is still aware of pending patches via
the mailing list.

Please let me know if you have questions of other suggestions.

As a kernel.org mdadm maintainer, I will keep kernel.org repo and Github
in-sync for both master/main branches. Although they will be kept
in sync, developers should consider GitHub/main effective immediately
after merging this patchset.

I will wait at least one week with merge to gather feedback and resolve
objections. Feel free to ask.

Cc: Paul E Luse <paul.e.luse@linux.intel.com>
Cc: Song Liu <song@kernel.org>
Cc: Kinga Tanska <kinga.tanska@linux.intel.com>
Cc: Jes Sorensen <jes@trained-monkey.org>

Mariusz Tkaczyk (1):
  mdadm: Change main repository to Github

 MAINTAINERS.md | 41 +++++++++++----------------------
 README.md      | 61 ++++++++++++++++++++------------------------------
 2 files changed, 37 insertions(+), 65 deletions(-)

-- 
2.35.3

[PATCH 1/1] mdadm: Change main repository to Github

[Mariusz Tkaczyk]

Now github will be used for tracking mdadm, adjust README.md.
Daily routines will be automated on Github, there is not need to
describe 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      | 61 ++++++++++++++++++++------------------------------
 2 files changed, 37 insertions(+), 65 deletions(-)

diff --git a/MAINTAINERS.md b/MAINTAINERS.md
index 9c79ba8748cd..e5b635f02d65 100644
--- a/MAINTAINERS.md
+++ b/MAINTAINERS.md
@@ -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.
diff --git a/README.md b/README.md
index 64f2ecec784e..0f9eccaf7f07 100644
--- a/README.md
+++ b/README.md
@@ -20,58 +20,45 @@
     **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
+# How to Ask
 
- **mdadm** is hosted on [kernel.org](https://kernel.org/). You can access repository
-[here](https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git).
+You can use either Github panels (Issues or Discussions) on
+[Github](https://github.com/md-raid-utilities/mdadm) or ask on
+[Mailing List](https://lore.kernel.org/linux-raid/).
 
-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**.
+While we are transitioning to GitHub, you may want to use the Mailing List in order to reach a wider
+audience. Also, please use the Mailing list for all questions not specifically related to mdadm
+itself (mdraid, etc).
 
-## Sending patches step-by-step
+# How to Contribute
 
-To maximize change of patches being taken, follow this instruction when submitting:
+Effective immediately [Github](https://github.com/md-raid-utilities/mdadm) is the primary
+location for **mdadm**. Use pull request to contribute.
 
-1. Create possibly logically separated commits and generate patches:
+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).
 
-   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.
+**Patches sent through Mailing List are no longer accepted.**
 
-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
-- 
2.35.3

Re: [PATCH 0/1] Move mdadm development to Github

[Paul Menzel]

Dear Mariusz,


Thank for bringing this topic up for discussion. Unfortunately, I have 
to reply with negative comments.


Am 19.04.24 um 03:48 schrieb Mariusz Tkaczyk:
> Thanks to Song and Paul, we created organization for md-raid on Github.
> This is a perfect place to maintain mdadm. I would like announce moving
> mdadm development to Github.
> 
> It is already forked, feel free to explore:
> https://github.com/md-raid-utilities/mdadm
> 
> Github is powerful and it has well integrated CI. On the repo, you can
> already find a pull request which will add compilation and code style
> tests (Thanks to Kinga!).
> This is MORE than we have now so I believe that with the change mdadm
> stability and code quality will be increased. The participating method
> will be simplified, it is really easy to create pull request. Also,
> anyone can fork repo with base tests included and properly configured.
> 
> Note that Song and Paul are working on a per patch CI system using GitHub
> Actions and a dedicated rack of servers to enable fast container, VM and
> bare metal testing for both mdraid and mdadm. Having mdadm on GitHub will
> help with that integration.

Improved testing sounds good. Thank you. I do not think though, that 
using GitHub is a requirement for that, and there are a lot of bots on 
the Linux kernel mailing list doing this without GitHub.

> As a result of moving to GitHub, we will no longer be using mailing list
> to propose patches, we will be using GitHub Pull Requests (PRs). As the
> community adjusts to using PRs I will be setting up auto-notification
> for those who attempt to use email for patches to let them know that we
> now use PRs.  I will also setup GitHub to send email to the mailing list
> on each new PR so that everyone is still aware of pending patches via
> the mailing list.

In my experience, using GitHub for code review is far inferior to using 
mailing lists or Gerrit. First, you cannot comment on the commit 
message. As a result, projects using GitHub have a really low-quality 
git history. Also, you only cannot comment single parts of a line in the 
diff.

The “one thread” discussion model is also a pain, as most people using 
Web forms do not correctly cite and quote, and with more than three 
answers you loose the overview. For some reason people think more about 
their reply, using mailing lists than Web forms.

Using different forums for discussions should also not be allowed. 
People should just subscribe and monitor one forum.

So, I strongly oppose this move, but I am also aware, that I am not 
doing a lot of development contribution.


Kind regards,

Paul

Re: [PATCH 0/1] Move mdadm development to Github

[Mariusz Tkaczyk]

On Fri, 26 Apr 2024 08:46:18 +0200
Paul Menzel <pmenzel@molgen.mpg.de> wrote:

> Dear Mariusz,
> 
> 
> Thank for bringing this topic up for discussion. Unfortunately, I have 
> to reply with negative comments.
> 
> 
> Am 19.04.24 um 03:48 schrieb Mariusz Tkaczyk:
> > Thanks to Song and Paul, we created organization for md-raid on Github.
> > This is a perfect place to maintain mdadm. I would like announce moving
> > mdadm development to Github.
> > 
> > It is already forked, feel free to explore:
> > https://github.com/md-raid-utilities/mdadm
> > 
> > Github is powerful and it has well integrated CI. On the repo, you can
> > already find a pull request which will add compilation and code style
> > tests (Thanks to Kinga!).
> > This is MORE than we have now so I believe that with the change mdadm
> > stability and code quality will be increased. The participating method
> > will be simplified, it is really easy to create pull request. Also,
> > anyone can fork repo with base tests included and properly configured.
> > 
> > Note that Song and Paul are working on a per patch CI system using GitHub
> > Actions and a dedicated rack of servers to enable fast container, VM and
> > bare metal testing for both mdraid and mdadm. Having mdadm on GitHub will
> > help with that integration.  
> 
> Improved testing sounds good. Thank you. I do not think though, that 
> using GitHub is a requirement for that, and there are a lot of bots on 
> the Linux kernel mailing list doing this without GitHub.

Hi Paul,

At some point Paul Luse and Song Liu decided that they will choose Github for MD
CI and Paul is busy working on creating dedicated Github runners for MD CI.
Moving mdadm development then is a logical next step as I want to reuse the
prepared hardware resources simple way.

> 
> > As a result of moving to GitHub, we will no longer be using mailing list
> > to propose patches, we will be using GitHub Pull Requests (PRs). As the
> > community adjusts to using PRs I will be setting up auto-notification
> > for those who attempt to use email for patches to let them know that we
> > now use PRs.  I will also setup GitHub to send email to the mailing list
> > on each new PR so that everyone is still aware of pending patches via
> > the mailing list.  
> 
> In my experience, using GitHub for code review is far inferior to using 
> mailing lists or Gerrit. First, you cannot comment on the commit 
> message. As a result, projects using GitHub have a really low-quality 
> git history. Also, you only cannot comment single parts of a line in the 
> diff.

These are known limitations. I understand your objections here.

We have to accept them. Commits will be as good as maintainers cares about them.
Please keep in mind that except Intel, the activity around mdadm is low.
I'm receiving 1 patchset within 2 weeks. I can deal with those limitations and
I don't need customized and advanced solution with huge maintenance cost (at
least for now). If that will be changed- we will propose something else.

There are many Github actions we can setup to help us with review.

>
> The “one thread” discussion model is also a pain, as most people using 
> Web forms do not correctly cite and quote, and with more than three 
> answers you loose the overview. For some reason people think more about 
> their reply, using mailing lists than Web forms.

We cannot ban less experienced users from participating. I want to make mdadm
development more attractive. I know that generally folks here are well
experienced in Linux netiquette, having github will change that.

It is another trade-off I agree to take.

> 
> Using different forums for discussions should also not be allowed. 
> People should just subscribe and monitor one forum.

For young developers Github is natural work environment. If they want to to
fill issue (as they do for thousand other projects)- they can. If github mdadm
maintainers cannot support them, we will redirect them to mailing list for
wider audience.

> 
> So, I strongly oppose this move, but I am also aware, that I am not 
> doing a lot of development contribution.

The true is that mdadm is a small and "simple" userspace project. There is not a
tons of development around it. Please help me keep simple things simple.
We can achieve CI, (probably) "sufficient" review system and simplified well
known on market participating process in few clicks. Maintenance of review
solution will not belong to us (expect custom GH runners).

For these reasons, I see it a natural next step to grow but I'm also familiar
with Github limitations. I have to deal with them in other projects I'm
maintaining or participating. 

I also know that I can count of support from Linux Foundation in case of special
needs (like additional resources). That is also great.

Thanks,
Mariusz

Re: [PATCH 0/1] Move mdadm development to Github

[Paul Menzel]

Dear Mariusz,


Thank you for your quick reply.

Am 26.04.24 um 10:36 schrieb Mariusz Tkaczyk:
> On Fri, 26 Apr 2024 08:46:18 +0200 Paul Menzel wrote:

>> Thank for bringing this topic up for discussion. Unfortunately, I have
>> to reply with negative comments.
>>
>> Am 19.04.24 um 03:48 schrieb Mariusz Tkaczyk:
>>> Thanks to Song and Paul, we created organization for md-raid on Github.
>>> This is a perfect place to maintain mdadm. I would like announce moving
>>> mdadm development to Github.
>>>
>>> It is already forked, feel free to explore:
>>> https://github.com/md-raid-utilities/mdadm
>>>
>>> Github is powerful and it has well integrated CI. On the repo, you can
>>> already find a pull request which will add compilation and code style
>>> tests (Thanks to Kinga!).
>>> This is MORE than we have now so I believe that with the change mdadm
>>> stability and code quality will be increased. The participating method
>>> will be simplified, it is really easy to create pull request. Also,
>>> anyone can fork repo with base tests included and properly configured.
>>>
>>> Note that Song and Paul are working on a per patch CI system using GitHub
>>> Actions and a dedicated rack of servers to enable fast container, VM and
>>> bare metal testing for both mdraid and mdadm. Having mdadm on GitHub will
>>> help with that integration.
>>
>> Improved testing sounds good. Thank you. I do not think though, that
>> using GitHub is a requirement for that, and there are a lot of bots on
>> the Linux kernel mailing list doing this without GitHub.

> At some point Paul Luse and Song Liu decided that they will choose Github for MD
> CI and Paul is busy working on creating dedicated Github runners for MD CI.
> Moving mdadm development then is a logical next step as I want to reuse the
> prepared hardware resources simple way.
> 
>>> As a result of moving to GitHub, we will no longer be using mailing list
>>> to propose patches, we will be using GitHub Pull Requests (PRs). As the
>>> community adjusts to using PRs I will be setting up auto-notification
>>> for those who attempt to use email for patches to let them know that we
>>> now use PRs.  I will also setup GitHub to send email to the mailing list
>>> on each new PR so that everyone is still aware of pending patches via
>>> the mailing list.
>>
>> In my experience, using GitHub for code review is far inferior to using
>> mailing lists or Gerrit. First, you cannot comment on the commit
>> message. As a result, projects using GitHub have a really low-quality
>> git history. Also, you only cannot comment single parts of a line in the
>> diff.
> 
> These are known limitations. I understand your objections here.

It would be nice, if you listed them in your proposal with solutions how 
to address them. That would have avoided them.

> We have to accept them.

I do not think so. Why?

> Commits will be as good as maintainers cares about them. Please keep
> in mind that except Intel, the activity around mdadm is low. I'm
> receiving 1 patchset within 2 weeks. I can deal with those
> limitations and I don't need customized and advanced solution with
> huge maintenance cost (at least for now). If that will be changed- we
> will propose something else.
If it is that low, then I do not understand, why the infrastructure 
needs to be changed at all.

> There are many Github actions we can setup to help us with review.

Can you please give example projects, that have implemented that on GitHub?

>> The “one thread” discussion model is also a pain, as most people using
>> Web forms do not correctly cite and quote, and with more than three
>> answers you loose the overview. For some reason people think more about
>> their reply, using mailing lists than Web forms.
> 
> We cannot ban less experienced users from participating. I want to make mdadm
> development more attractive. I know that generally folks here are well
> experienced in Linux netiquette, having github will change that.

Has this claim ever been proven, now that a lot of projects made the 
switch. Did participation actually increase?

> It is another trade-off I agree to take.
> 
>> Using different forums for discussions should also not be allowed.
>> People should just subscribe and monitor one forum.
> 
> For young developers Github is natural work environment. If they want
> to to file issue (as they do for thousand other projects) - they can.
> If github mdadm maintainers cannot support them, we will redirect
> them to mailing list for wider audience.
As written, I do not think splitting forums (for a small project) is a 
good idea.

>> So, I strongly oppose this move, but I am also aware, that I am not
>> doing a lot of development contribution.
> 
> The truth is that mdadm is a small and "simple" userspace project.
> There is not a tons of development around it. Please help me keep
> simple things simple.
As written above, if that is true, I do not understand the effort put 
into changing the infrastructure. The effort could have gone into 
writing the CI infrastructure for a mailing list process. Other Intel 
departments seem to do it already, so work would not need to be reinvented?

> We can achieve CI, (probably) "sufficient" review system and
> simplified well known on market participating process in few clicks.
> Maintenance of review solution will not belong to us (expect custom
> GH runners).

Sorry, I do not understand.

> For these reasons, I see it a natural next step to grow but I'm also
> familiar with Github limitations. I have to deal with them in other
> projects I'm maintaining or participating.

I am not convinced the theoretical more participants are outweighing the 
cost for the existing folks being happy with the current infrastructure.

> I also know that I can count of support from Linux Foundation in case
> of special needs (like additional resources). That is also great.

Sorry, I also do not understand this statement. Is the Linux Foundation 
only supporting projects using a GitHub based workflow?


Kind regards,

Paul

Re: [PATCH 0/1] Move mdadm development to Github

[Mariusz Tkaczyk]

Hi Paul,
I will disable "Discussions" panel on Github. That make sense to ask people to
direct question to ML. I will try to keep "Issues" related to mdadm only.
Otherwise we will redirect people to ML. For example, in case when someone is
looking for help how to recover array it should be directed to ML not Github.

I think that sending notification about new pull request will be enough for
interested folks to take a look and eventually comment. So I still would like
to do review outside ML but if there is a need to consult feature/bugfix it can
be sent to ML as RFC to get wider community support.

It is not one way move, we have to do what is reasonable and necessary for
mdadm to grow. It is not that we are moving to github and abandoning ML. It is
and always will be a part of mdadm and can be used if needed.

More detailed answers below.
Thanks,
Mariusz

On Fri, 26 Apr 2024 11:52:05 +0200
Paul Menzel <pmenzel@molgen.mpg.de> wrote:

> Dear Mariusz,
> 
> 
> Thank you for your quick reply.
> 
> Am 26.04.24 um 10:36 schrieb Mariusz Tkaczyk:
> > On Fri, 26 Apr 2024 08:46:18 +0200 Paul Menzel wrote:  
> 
> >> Thank for bringing this topic up for discussion. Unfortunately, I have
> >> to reply with negative comments.
> >>
> >> Am 19.04.24 um 03:48 schrieb Mariusz Tkaczyk:  
> >>> Thanks to Song and Paul, we created organization for md-raid on Github.
> >>> This is a perfect place to maintain mdadm. I would like announce moving
> >>> mdadm development to Github.
> >>>
> >>> It is already forked, feel free to explore:
> >>> https://github.com/md-raid-utilities/mdadm
> >>>
> >>> Github is powerful and it has well integrated CI. On the repo, you can
> >>> already find a pull request which will add compilation and code style
> >>> tests (Thanks to Kinga!).
> >>> This is MORE than we have now so I believe that with the change mdadm
> >>> stability and code quality will be increased. The participating method
> >>> will be simplified, it is really easy to create pull request. Also,
> >>> anyone can fork repo with base tests included and properly configured.
> >>>
> >>> Note that Song and Paul are working on a per patch CI system using GitHub
> >>> Actions and a dedicated rack of servers to enable fast container, VM and
> >>> bare metal testing for both mdraid and mdadm. Having mdadm on GitHub will
> >>> help with that integration.  
> >>
> >> Improved testing sounds good. Thank you. I do not think though, that
> >> using GitHub is a requirement for that, and there are a lot of bots on
> >> the Linux kernel mailing list doing this without GitHub.  
> 
> > At some point Paul Luse and Song Liu decided that they will choose Github
> > for MD CI and Paul is busy working on creating dedicated Github runners for
> > MD CI. Moving mdadm development then is a logical next step as I want to
> > reuse the prepared hardware resources simple way.
> >   
> >>> As a result of moving to GitHub, we will no longer be using mailing list
> >>> to propose patches, we will be using GitHub Pull Requests (PRs). As the
> >>> community adjusts to using PRs I will be setting up auto-notification
> >>> for those who attempt to use email for patches to let them know that we
> >>> now use PRs.  I will also setup GitHub to send email to the mailing list
> >>> on each new PR so that everyone is still aware of pending patches via
> >>> the mailing list.  
> >>
> >> In my experience, using GitHub for code review is far inferior to using
> >> mailing lists or Gerrit. First, you cannot comment on the commit
> >> message. As a result, projects using GitHub have a really low-quality
> >> git history. Also, you only cannot comment single parts of a line in the
> >> diff.  
> > 
> > These are known limitations. I understand your objections here.  
> 
> It would be nice, if you listed them in your proposal with solutions how 
> to address them. That would have avoided them.

This particular problem (commit messages quality) must be addressed by review
process itself so nothing fancy to list. We are responsible for the commits
which are comes to repository, wherever they are reviewed. At minimal,
checkpatch action will be done on each commit in PR, you can see it proposed
here:
https://github.com/md-raid-utilities/mdadm/pull/2

For the Github review GUI limitations, we have to accept them. It will be
reviewer task to make comment clear to help author move this forward. You can
copy part of the commit message to comment and add link to it and say what you
want. Github has nice markdown support reviewer should use it to make it easier
to follow. For example, this is my comment in different project:
https://github.com/intel/ledmon/pull/193#issuecomment-1941462964
Isn't it clear?

> 
> > We have to accept them.  
> 
> I do not think so. Why?

Because I think that what Github offers if enough to develop mdadm.
I don't want to reinvent the wheel because we sticked to different work
model. As I want to take this step I'm going to take what makes sense, what
gives a value and what makes developer participation easier.

That should work for 90% of patches. If we are in doubts we can always send RFC
to ML to get support.

> 
> > Commits will be as good as maintainers cares about them. Please keep
> > in mind that except Intel, the activity around mdadm is low. I'm
> > receiving 1 patchset within 2 weeks. I can deal with those
> > limitations and I don't need customized and advanced solution with
> > huge maintenance cost (at least for now). If that will be changed- we
> > will propose something else.  
> If it is that low, then I do not understand, why the infrastructure 
> needs to be changed at all.

Because we want to add real CI testing and avoid maintaining it. We will have
just Github, nothing more than that. Simple development process, everyone can
contribute. It does not require to be familiarized with ML in standard cases
(for example to fix compilation issue).

> 
> > There are many Github actions we can setup to help us with review.  
> 
> Can you please give example projects, that have implemented that on GitHub?

https://github.com/md-raid-utilities/mdadm/pull/2
Above you have pull to mdadm which provides base testing:
- default gcc checks with various CXFLAGS
- checkpatch checks
Next, real tests will be added (we will start with enabling mdadm tests) but to
make that we need custom GH runners.

You can see well developed checks in dracut project:
https://github.com/dracutdevs/dracut/pull/2643/checks

> 
> >> The “one thread” discussion model is also a pain, as most people using
> >> Web forms do not correctly cite and quote, and with more than three
> >> answers you loose the overview. For some reason people think more about
> >> their reply, using mailing lists than Web forms.  
> > 
> > We cannot ban less experienced users from participating. I want to make
> > mdadm development more attractive. I know that generally folks here are well
> > experienced in Linux netiquette, having github will change that.  
> 
> Has this claim ever been proven, now that a lot of projects made the 
> switch. Did participation actually increase?

For sure moving ledmon from sourceforge to github increased its visibility. I
know because I was in the team at this time:
https://github.com/intel/ledmon

However, I'm not sure if that is example you are looking for. I think that
dracut matches better here. You can see that development on github is really
active but I don't know how it was in the past. For sure, it didn't kill dracut.
https://github.com/dracutdevs/dracut

> 
> > It is another trade-off I agree to take.
> >   
> >> Using different forums for discussions should also not be allowed.
> >> People should just subscribe and monitor one forum.  
> > 
> > For young developers Github is natural work environment. If they want
> > to to file issue (as they do for thousand other projects) - they can.
> > If github mdadm maintainers cannot support them, we will redirect
> > them to mailing list for wider audience.  
> As written, I do not think splitting forums (for a small project) is a 
> good idea.

On github I can enable issues, discussions and wiki tabs. I can also create
dedicated github.io site:
https://pages.github.com/

This all waiting and we can use that but we don't have to. I totally agree now
that it is better to keep discussions and support in one source, so here is my
proposal:
- issues will be used to report bugs for mdadm. *For bugs*, not for reaching
  help with failed scenarios, suggestions etc.
- discussions - I will disable it because it should take place on ML.
- wiki - we have raid wiki so for now I will disable it, unless we would like
  to start noting some mdadm related information (know issues in mdadm, low
  level tasks for new developers to participate, how to compile,
  development tricks etc.) only mdadm development related things.

Anything else, goto ML.

What do you think? Can it work?

> 
> >> So, I strongly oppose this move, but I am also aware, that I am not
> >> doing a lot of development contribution.  
> > 
> > The truth is that mdadm is a small and "simple" userspace project.
> > There is not a tons of development around it. Please help me keep
> > simple things simple.  
> As written above, if that is true, I do not understand the effort put 
> into changing the infrastructure. The effort could have gone into 
> writing the CI infrastructure for a mailing list process. Other Intel 
> departments seem to do it already, so work would not need to be reinvented?

Are you asking about lkp@intel.com kernel test robot? This robot is kernel only
- I asked them in the past.

I think that Paul Luse can comment here more but I think that removing mdadm
patches from ML will make an effort of creating CI for MD simpler because
there will be no patches related to other project, kernel only.

Whatever requires maintenance on any side increases complexity and I think that
mdadm is not enough big to increase complexity. We can just use github only and
reuse runners, initially created for MD testing. Any script, or daemon working
in background must be hosted somewhere (and someone needs to care
about it). I don't want that because I think that it is not necessary.

> 
> > We can achieve CI, (probably) "sufficient" review system and
> > simplified well known on market participating process in few clicks.
> > Maintenance of review solution will not belong to us (expect custom
> > GH runners).  
> 
> Sorry, I do not understand.

I meant that on Github we can simply achieve review and CI systems with no
additional work. The one change is only where mdadm patches are sent.

From developer perspective Github workflow is easier.

> 
> > For these reasons, I see it a natural next step to grow but I'm also
> > familiar with Github limitations. I have to deal with them in other
> > projects I'm maintaining or participating.  
> 
> I am not convinced the theoretical more participants are outweighing the 
> cost for the existing folks being happy with the current infrastructure.

You and I are reviewers of mdadm patches mainly. Comments from other people are
sporadic. Thank you for all work but it is not enough. I need to try building
mdadm developers community and here we are shadow of MD.

Mdadm has other problems, people here are rarely interested in fixing them.

But still some RFC's for mdadm would be send here - we can always request that
on Github. As a reviewers we need to ensure that the change is good so if we are
not sure, reaching mailing list would be crucial.

Does it work for you?

> 
> > I also know that I can count of support from Linux Foundation in case
> > of special needs (like additional resources). That is also great.  
> 
> Sorry, I also do not understand this statement. Is the Linux Foundation 
> only supporting projects using a GitHub based workflow?
> 

No, I meant that if there will be a need to they can help me reach Microsoft to
get more resources, but since we have create make our own runners then probably
this point has no sense. Sorry!

Thanks,
Mariusz

Re: [PATCH 0/1] Move mdadm development to Github

[Paul E Luse]

FWIW I support the move for the reasons Mariusz outlines. Everyone
will, of course, have their own perosnal preferences based on
expeirences, etc (I for one am a HUGE fan of Gerrit over any other
review system).

An important thing to keep in mind is that course correction is always
possible and it can be hard to predict how changes may or may not play
out well without taking some risks.

Now, not making attempts to improve communcations and quality (given
of course that opinions will vary and all of them matter) I think is a
recipe for stagnation.

Just my 2 cents :)
-Paul

On Fri, 26 Apr 2024 15:59:09 +0200
Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> wrote:

> Hi Paul,
> I will disable "Discussions" panel on Github. That make sense to ask
> people to direct question to ML. I will try to keep "Issues" related
> to mdadm only. Otherwise we will redirect people to ML. For example,
> in case when someone is looking for help how to recover array it
> should be directed to ML not Github.
> 
> I think that sending notification about new pull request will be
> enough for interested folks to take a look and eventually comment. So
> I still would like to do review outside ML but if there is a need to
> consult feature/bugfix it can be sent to ML as RFC to get wider
> community support.
> 
> It is not one way move, we have to do what is reasonable and
> necessary for mdadm to grow. It is not that we are moving to github
> and abandoning ML. It is and always will be a part of mdadm and can
> be used if needed.
> 
> More detailed answers below.
> Thanks,
> Mariusz
> 
> On Fri, 26 Apr 2024 11:52:05 +0200
> Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> 
> > Dear Mariusz,
> > 
> > 
> > Thank you for your quick reply.
> > 
> > Am 26.04.24 um 10:36 schrieb Mariusz Tkaczyk:
> > > On Fri, 26 Apr 2024 08:46:18 +0200 Paul Menzel wrote:  
> > 
> > >> Thank for bringing this topic up for discussion. Unfortunately,
> > >> I have to reply with negative comments.
> > >>
> > >> Am 19.04.24 um 03:48 schrieb Mariusz Tkaczyk:  
> > >>> Thanks to Song and Paul, we created organization for md-raid on
> > >>> Github. This is a perfect place to maintain mdadm. I would like
> > >>> announce moving mdadm development to Github.
> > >>>
> > >>> It is already forked, feel free to explore:
> > >>> https://github.com/md-raid-utilities/mdadm
> > >>>
> > >>> Github is powerful and it has well integrated CI. On the repo,
> > >>> you can already find a pull request which will add compilation
> > >>> and code style tests (Thanks to Kinga!).
> > >>> This is MORE than we have now so I believe that with the change
> > >>> mdadm stability and code quality will be increased. The
> > >>> participating method will be simplified, it is really easy to
> > >>> create pull request. Also, anyone can fork repo with base tests
> > >>> included and properly configured.
> > >>>
> > >>> Note that Song and Paul are working on a per patch CI system
> > >>> using GitHub Actions and a dedicated rack of servers to enable
> > >>> fast container, VM and bare metal testing for both mdraid and
> > >>> mdadm. Having mdadm on GitHub will help with that integration.  
> > >>
> > >> Improved testing sounds good. Thank you. I do not think though,
> > >> that using GitHub is a requirement for that, and there are a lot
> > >> of bots on the Linux kernel mailing list doing this without
> > >> GitHub.  
> > 
> > > At some point Paul Luse and Song Liu decided that they will
> > > choose Github for MD CI and Paul is busy working on creating
> > > dedicated Github runners for MD CI. Moving mdadm development then
> > > is a logical next step as I want to reuse the prepared hardware
> > > resources simple way. 
> > >>> As a result of moving to GitHub, we will no longer be using
> > >>> mailing list to propose patches, we will be using GitHub Pull
> > >>> Requests (PRs). As the community adjusts to using PRs I will be
> > >>> setting up auto-notification for those who attempt to use email
> > >>> for patches to let them know that we now use PRs.  I will also
> > >>> setup GitHub to send email to the mailing list on each new PR
> > >>> so that everyone is still aware of pending patches via the
> > >>> mailing list.  
> > >>
> > >> In my experience, using GitHub for code review is far inferior
> > >> to using mailing lists or Gerrit. First, you cannot comment on
> > >> the commit message. As a result, projects using GitHub have a
> > >> really low-quality git history. Also, you only cannot comment
> > >> single parts of a line in the diff.  
> > > 
> > > These are known limitations. I understand your objections here.  
> > 
> > It would be nice, if you listed them in your proposal with
> > solutions how to address them. That would have avoided them.
> 
> This particular problem (commit messages quality) must be addressed
> by review process itself so nothing fancy to list. We are responsible
> for the commits which are comes to repository, wherever they are
> reviewed. At minimal, checkpatch action will be done on each commit
> in PR, you can see it proposed here:
> https://github.com/md-raid-utilities/mdadm/pull/2
> 
> For the Github review GUI limitations, we have to accept them. It
> will be reviewer task to make comment clear to help author move this
> forward. You can copy part of the commit message to comment and add
> link to it and say what you want. Github has nice markdown support
> reviewer should use it to make it easier to follow. For example, this
> is my comment in different project:
> https://github.com/intel/ledmon/pull/193#issuecomment-1941462964
> Isn't it clear?
> 
> > 
> > > We have to accept them.  
> > 
> > I do not think so. Why?
> 
> Because I think that what Github offers if enough to develop mdadm.
> I don't want to reinvent the wheel because we sticked to different
> work model. As I want to take this step I'm going to take what makes
> sense, what gives a value and what makes developer participation
> easier.
> 
> That should work for 90% of patches. If we are in doubts we can
> always send RFC to ML to get support.
> 
> > 
> > > Commits will be as good as maintainers cares about them. Please
> > > keep in mind that except Intel, the activity around mdadm is low.
> > > I'm receiving 1 patchset within 2 weeks. I can deal with those
> > > limitations and I don't need customized and advanced solution with
> > > huge maintenance cost (at least for now). If that will be
> > > changed- we will propose something else.  
> > If it is that low, then I do not understand, why the infrastructure 
> > needs to be changed at all.
> 
> Because we want to add real CI testing and avoid maintaining it. We
> will have just Github, nothing more than that. Simple development
> process, everyone can contribute. It does not require to be
> familiarized with ML in standard cases (for example to fix
> compilation issue).
> 
> > 
> > > There are many Github actions we can setup to help us with
> > > review.  
> > 
> > Can you please give example projects, that have implemented that on
> > GitHub?
> 
> https://github.com/md-raid-utilities/mdadm/pull/2
> Above you have pull to mdadm which provides base testing:
> - default gcc checks with various CXFLAGS
> - checkpatch checks
> Next, real tests will be added (we will start with enabling mdadm
> tests) but to make that we need custom GH runners.
> 
> You can see well developed checks in dracut project:
> https://github.com/dracutdevs/dracut/pull/2643/checks
> 
> > 
> > >> The “one thread” discussion model is also a pain, as most people
> > >> using Web forms do not correctly cite and quote, and with more
> > >> than three answers you loose the overview. For some reason
> > >> people think more about their reply, using mailing lists than
> > >> Web forms.  
> > > 
> > > We cannot ban less experienced users from participating. I want
> > > to make mdadm development more attractive. I know that generally
> > > folks here are well experienced in Linux netiquette, having
> > > github will change that.  
> > 
> > Has this claim ever been proven, now that a lot of projects made
> > the switch. Did participation actually increase?
> 
> For sure moving ledmon from sourceforge to github increased its
> visibility. I know because I was in the team at this time:
> https://github.com/intel/ledmon
> 
> However, I'm not sure if that is example you are looking for. I think
> that dracut matches better here. You can see that development on
> github is really active but I don't know how it was in the past. For
> sure, it didn't kill dracut. https://github.com/dracutdevs/dracut
> 
> > 
> > > It is another trade-off I agree to take.
> > >   
> > >> Using different forums for discussions should also not be
> > >> allowed. People should just subscribe and monitor one forum.  
> > > 
> > > For young developers Github is natural work environment. If they
> > > want to to file issue (as they do for thousand other projects) -
> > > they can. If github mdadm maintainers cannot support them, we
> > > will redirect them to mailing list for wider audience.  
> > As written, I do not think splitting forums (for a small project)
> > is a good idea.
> 
> On github I can enable issues, discussions and wiki tabs. I can also
> create dedicated github.io site:
> https://pages.github.com/
> 
> This all waiting and we can use that but we don't have to. I totally
> agree now that it is better to keep discussions and support in one
> source, so here is my proposal:
> - issues will be used to report bugs for mdadm. *For bugs*, not for
> reaching help with failed scenarios, suggestions etc.
> - discussions - I will disable it because it should take place on ML.
> - wiki - we have raid wiki so for now I will disable it, unless we
> would like to start noting some mdadm related information (know
> issues in mdadm, low level tasks for new developers to participate,
> how to compile, development tricks etc.) only mdadm development
> related things.
> 
> Anything else, goto ML.
> 
> What do you think? Can it work?
> 
> > 
> > >> So, I strongly oppose this move, but I am also aware, that I am
> > >> not doing a lot of development contribution.  
> > > 
> > > The truth is that mdadm is a small and "simple" userspace project.
> > > There is not a tons of development around it. Please help me keep
> > > simple things simple.  
> > As written above, if that is true, I do not understand the effort
> > put into changing the infrastructure. The effort could have gone
> > into writing the CI infrastructure for a mailing list process.
> > Other Intel departments seem to do it already, so work would not
> > need to be reinvented?
> 
> Are you asking about lkp@intel.com kernel test robot? This robot is
> kernel only
> - I asked them in the past.
> 
> I think that Paul Luse can comment here more but I think that
> removing mdadm patches from ML will make an effort of creating CI for
> MD simpler because there will be no patches related to other project,
> kernel only.
> 
> Whatever requires maintenance on any side increases complexity and I
> think that mdadm is not enough big to increase complexity. We can
> just use github only and reuse runners, initially created for MD
> testing. Any script, or daemon working in background must be hosted
> somewhere (and someone needs to care about it). I don't want that
> because I think that it is not necessary.
> 
> > 
> > > We can achieve CI, (probably) "sufficient" review system and
> > > simplified well known on market participating process in few
> > > clicks. Maintenance of review solution will not belong to us
> > > (expect custom GH runners).  
> > 
> > Sorry, I do not understand.
> 
> I meant that on Github we can simply achieve review and CI systems
> with no additional work. The one change is only where mdadm patches
> are sent.
> 
> From developer perspective Github workflow is easier.
> 
> > 
> > > For these reasons, I see it a natural next step to grow but I'm
> > > also familiar with Github limitations. I have to deal with them
> > > in other projects I'm maintaining or participating.  
> > 
> > I am not convinced the theoretical more participants are
> > outweighing the cost for the existing folks being happy with the
> > current infrastructure.
> 
> You and I are reviewers of mdadm patches mainly. Comments from other
> people are sporadic. Thank you for all work but it is not enough. I
> need to try building mdadm developers community and here we are
> shadow of MD.
> 
> Mdadm has other problems, people here are rarely interested in fixing
> them.
> 
> But still some RFC's for mdadm would be send here - we can always
> request that on Github. As a reviewers we need to ensure that the
> change is good so if we are not sure, reaching mailing list would be
> crucial.
> 
> Does it work for you?
> 
> > 
> > > I also know that I can count of support from Linux Foundation in
> > > case of special needs (like additional resources). That is also
> > > great.  
> > 
> > Sorry, I also do not understand this statement. Is the Linux
> > Foundation only supporting projects using a GitHub based workflow?
> > 
> 
> No, I meant that if there will be a need to they can help me reach
> Microsoft to get more resources, but since we have create make our
> own runners then probably this point has no sense. Sorry!
> 
> Thanks,
> Mariusz
> 

Re: [PATCH 0/1] Move mdadm development to Github

[Jes Sorensen]

Disappointed to see this :(

The github interface is not a favorite. Mailing lists are the way open source projects work.

I haven't had much time to contribute for quite a while now and probably won't in the near future. Given this decision was made without my involvement, I'll sign off.

Jes 


-----Original Message-----
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: linux-raid@vger.kernel.org
Cc: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>, Paul E Luse <paul.e.luse@linux.intel.com>, Song Liu <song@kernel.org>, Kinga Tanska <kinga.tanska@linux.intel.com>, Jes Sorensen <jes@trained-monkey.org>
Sent: Fri, 19 Apr 2024 5:39
Subject: [PATCH 0/1] Move mdadm development to Github

Thanks to Song and Paul, we created organization for md-raid on Github.
This is a perfect place to maintain mdadm. I would like announce moving
mdadm development to Github.

It is already forked, feel free to explore:
https://github.com/md-raid-utilities/mdadm

Github is powerful and it has well integrated CI. On the repo, you can
already find a pull request which will add compilation and code style
tests (Thanks to Kinga!).
This is MORE than we have now so I believe that with the change mdadm
stability and code quality will be increased. The participating method
will be simplified, it is really easy to create pull request. Also,
anyone can fork repo with base tests included and properly configured.

Note that Song and Paul are working on a per patch CI system using GitHub
Actions and a dedicated rack of servers to enable fast container, VM and
bare metal testing for both mdraid and mdadm. Having mdadm on GitHub will
help with that integration.

As a result of moving to GitHub, we will no longer be using mailing list
to propose patches, we will be using GitHub Pull Requests (PRs). As the
community adjusts to using PRs I will be setting up auto-notification
for those who attempt to use email for patches to let them know that we
now use PRs.  I will also setup GitHub to send email to the mailing list
on each new PR so that everyone is still aware of pending patches via
the mailing list.

Please let me know if you have questions of other suggestions.

As a kernel.org mdadm maintainer, I will keep kernel.org repo and Github
in-sync for both master/main branches. Although they will be kept
in sync, developers should consider GitHub/main effective immediately
after merging this patchset.

I will wait at least one week with merge to gather feedback and resolve
objections. Feel free to ask.

Cc: Paul E Luse <paul.e.luse@linux.intel.com>
Cc: Song Liu <song@kernel.org>
Cc: Kinga Tanska <kinga.tanska@linux.intel.com>
Cc: Jes Sorensen <jes@trained-monkey.org>

Mariusz Tkaczyk (1):
  mdadm: Change main repository to Github

 MAINTAINERS.md | 41 +++++++++++----------------------
 README.md      | 61 ++++++++++++++++++++------------------------------
 2 files changed, 37 insertions(+), 65 deletions(-)

-- 
2.35.3

Re: [PATCH 0/1] Move mdadm development to Github

[Paul E Luse]

On Mon, 29 Apr 2024 22:52:46 -0400
Jes Sorensen <jes@trained-monkey.org> wrote:

> Disappointed to see this :(
> 
> The github interface is not a favorite. Mailing lists are the way
> open source projects work.
> 
> I haven't had much time to contribute for quite a while now and
> probably won't in the near future. Given this decision was made
> without my involvement, I'll sign off.
> 
> Jes 
> 

Applaud the decision to 'sign off' despite personal preferences. I am
confident if things start going in the wrong direction that Mariusz
will course correct accordingly.

Thanks Jes :)

-Paul

> 
> -----Original Message-----
> From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
> To: linux-raid@vger.kernel.org
> Cc: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>, Paul E Luse
> <paul.e.luse@linux.intel.com>, Song Liu <song@kernel.org>, Kinga
> Tanska <kinga.tanska@linux.intel.com>, Jes Sorensen
> <jes@trained-monkey.org> Sent: Fri, 19 Apr 2024 5:39 Subject: [PATCH
> 0/1] Move mdadm development to Github
> 
> Thanks to Song and Paul, we created organization for md-raid on
> Github. This is a perfect place to maintain mdadm. I would like
> announce moving mdadm development to Github.
> 
> It is already forked, feel free to explore:
> https://github.com/md-raid-utilities/mdadm
> 
> Github is powerful and it has well integrated CI. On the repo, you can
> already find a pull request which will add compilation and code style
> tests (Thanks to Kinga!).
> This is MORE than we have now so I believe that with the change mdadm
> stability and code quality will be increased. The participating method
> will be simplified, it is really easy to create pull request. Also,
> anyone can fork repo with base tests included and properly configured.
> 
> Note that Song and Paul are working on a per patch CI system using
> GitHub Actions and a dedicated rack of servers to enable fast
> container, VM and bare metal testing for both mdraid and mdadm.
> Having mdadm on GitHub will help with that integration.
> 
> As a result of moving to GitHub, we will no longer be using mailing
> list to propose patches, we will be using GitHub Pull Requests (PRs).
> As the community adjusts to using PRs I will be setting up
> auto-notification for those who attempt to use email for patches to
> let them know that we now use PRs.  I will also setup GitHub to send
> email to the mailing list on each new PR so that everyone is still
> aware of pending patches via the mailing list.
> 
> Please let me know if you have questions of other suggestions.
> 
> As a kernel.org mdadm maintainer, I will keep kernel.org repo and
> Github in-sync for both master/main branches. Although they will be
> kept in sync, developers should consider GitHub/main effective
> immediately after merging this patchset.
> 
> I will wait at least one week with merge to gather feedback and
> resolve objections. Feel free to ask.
> 
> Cc: Paul E Luse <paul.e.luse@linux.intel.com>
> Cc: Song Liu <song@kernel.org>
> Cc: Kinga Tanska <kinga.tanska@linux.intel.com>
> Cc: Jes Sorensen <jes@trained-monkey.org>
> 
> Mariusz Tkaczyk (1):
>   mdadm: Change main repository to Github
> 
>  MAINTAINERS.md | 41 +++++++++++----------------------
>  README.md      | 61
> ++++++++++++++++++++------------------------------ 2 files changed,
> 37 insertions(+), 65 deletions(-)
> 

Re: [PATCH 0/1] Move mdadm development to Github

[Jes Sorensen]

Sorry for the obnoxious top posting, not near a computer right now. 

This was not meant as a signed-off-by, but rather I'm signing off the project. 

Good luck 

Sent from MailDroid

-----Original Message-----
From: Paul E Luse <paul.e.luse@linux.intel.com>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: linux-raid@vger.kernel.org, Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>, Song Liu <song@kernel.org>, Kinga Tanska <kinga.tanska@linux.intel.com>
Sent: Mon, 29 Apr 2024 23:40
Subject: Re: [PATCH 0/1] Move mdadm development to Github

On Mon, 29 Apr 2024 22:52:46 -0400
Jes Sorensen <jes@trained-monkey.org> wrote:

> Disappointed to see this :(
> 
> The github interface is not a favorite. Mailing lists are the way
> open source projects work.
> 
> I haven't had much time to contribute for quite a while now and
> probably won't in the near future. Given this decision was made
> without my involvement, I'll sign off.
> 
> Jes 
> 

Applaud the decision to 'sign off' despite personal preferences. I am
confident if things start going in the wrong direction that Mariusz
will course correct accordingly.

Thanks Jes :)

-Paul

> 
> -----Original Message-----
> From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
> To: linux-raid@vger.kernel.org
> Cc: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>, Paul E Luse
> <paul.e.luse@linux.intel.com>, Song Liu <song@kernel.org>, Kinga
> Tanska <kinga.tanska@linux.intel.com>, Jes Sorensen
> <jes@trained-monkey.org> Sent: Fri, 19 Apr 2024 5:39 Subject: [PATCH
> 0/1] Move mdadm development to Github
> 
> Thanks to Song and Paul, we created organization for md-raid on
> Github. This is a perfect place to maintain mdadm. I would like
> announce moving mdadm development to Github.
> 
> It is already forked, feel free to explore:
> https://github.com/md-raid-utilities/mdadm
> 
> Github is powerful and it has well integrated CI. On the repo, you can
> already find a pull request which will add compilation and code style
> tests (Thanks to Kinga!).
> This is MORE than we have now so I believe that with the change mdadm
> stability and code quality will be increased. The participating method
> will be simplified, it is really easy to create pull request. Also,
> anyone can fork repo with base tests included and properly configured.
> 
> Note that Song and Paul are working on a per patch CI system using
> GitHub Actions and a dedicated rack of servers to enable fast
> container, VM and bare metal testing for both mdraid and mdadm.
> Having mdadm on GitHub will help with that integration.
> 
> As a result of moving to GitHub, we will no longer be using mailing
> list to propose patches, we will be using GitHub Pull Requests (PRs).
> As the community adjusts to using PRs I will be setting up
> auto-notification for those who attempt to use email for patches to
> let them know that we now use PRs.  I will also setup GitHub to send
> email to the mailing list on each new PR so that everyone is still
> aware of pending patches via the mailing list.
> 
> Please let me know if you have questions of other suggestions.
> 
> As a kernel.org mdadm maintainer, I will keep kernel.org repo and
> Github in-sync for both master/main branches. Although they will be
> kept in sync, developers should consider GitHub/main effective
> immediately after merging this patchset.
> 
> I will wait at least one week with merge to gather feedback and
> resolve objections. Feel free to ask.
> 
> Cc: Paul E Luse <paul.e.luse@linux.intel.com>
> Cc: Song Liu <song@kernel.org>
> Cc: Kinga Tanska <kinga.tanska@linux.intel.com>
> Cc: Jes Sorensen <jes@trained-monkey.org>
> 
> Mariusz Tkaczyk (1):
>   mdadm: Change main repository to Github
> 
>  MAINTAINERS.md | 41 +++++++++++----------------------
>  README.md      | 61
> ++++++++++++++++++++------------------------------ 2 files changed,
> 37 insertions(+), 65 deletions(-)
>