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

[Paul Menzel <pmenzel@molgen.mpg.de>]

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