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
