On Fri, 26 Apr 2024 08:46:18 +0200 Paul Menzel <pmenzel@xxxxxxxxxxxxx> 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
