SRU of mdadm to Focal

mdadm-4.2 not released yet.
Feel free to close it if not applicable.

mdadm-4.2-rc-1 has been released officially.
Could you update the mdadm version?

mdadm-4.2-rc1 has been published in Impish. However, now that mdadm-4.2-rc2 has just been released and packaged in Debian, would it be possible to update it in Impish?

Just an update, rc2 is in -proposed for impish

Although we probably want to wait until the 4.2 release before going ahead with this, I've prepared a backport of 4.2~rc2-2ubuntu1 from impish to focal in a PPA:

https://launchpad.net/~ginggs/+archive/ubuntu/mdadm-backports

In the debdiff, I included only the packaging changes and filtered out the changelog and translations, etc. (filterdiff -i '*/debian/*' -x '*/debian/changelog' -x '*/debian/copyright' -x '*/debian/po/*' -x '*/debian/FAQ').

In addition, I removed the diff of all the patches that were dropped due to being included upstream, i.e.

-0001-Assemble-keep-MD_DISK_FAILFAST-and-MD_DISK_WRITEMOST.patch
-0002-Document-PART-POLICY-lines.patch
-0003-policy-support-devices-with-multiple-paths.patch
-0004-mdcheck-add-systemd-unit-files-to-run-mdcheck.patch
-0005-Monitor-add-system-timer-to-run-oneshot-periodically.patch
-0006-imsm-update-metadata-correctly-while-raid10-double-d.patch
-0007-Assemble-mask-FAILFAST-and-WRITEMOSTLY-flags-when-fi.patch
-0008-Grow-avoid-overflow-in-compute_backup_blocks.patch
-0009-Grow-report-correct-new-chunk-size.patch
-0010-policy.c-prevent-NULL-pointer-referencing.patch
-0011-policy.c-Fix-for-compiler-error.patch
-0001-Create-add-support-for-RAID0-layouts.patch
-0002-Assemble-add-support-for-RAID0-layouts.patch
-0001-Respect-CROSS_COMPILE-when-CC-is-the-default.patch
-lp-1847924-introduce-new-array-state-broken.patch
-mdcheck-log-when-done.patch
-mdcheck-when-mdcheck-start-is-enabled-mdcheck-continue-too.patch

Subscribing ~ubuntu-sru for comment.

With my SRU hat on: it's always a bit of a tricky situation whether we accept a completely new upstream version backport for a stable LTS series. In case of mdadm it's especially tricky, considering that 4.1 has been tagged (released) 3 years ago, meaning 4.2 has 3+ years of changes bundled up. And that always carries risks of regressing many users.

Per the SRU policy [1], generally we allow new upstream microreleases into stable series which carry changes fitting SRU criteria if the upstream project has:
 * a reliable and credible test suite for assuring the quality of every commit or release,
 * the tests are covering both functionality and API/ABI stability,
 * the tests run during package build to cover all architectures,
 * the package has an autopkgtest to run the tests in an Ubuntu environment against the actual binary packages

So these are the general policy guidelines. We can of course evaluate every project case-by-case, and not all of these points need to be strictly true (it would be hypocrisy to say we STRICTLY require that, as there are exceptions that we approved). But in general the idea is: we need to make sure that the upstream project has sufficiently strong testing story to make sure a minimal number of users can be potentially affected by any ABI/API breakages and/or general regressions.

I would appreciate some help in getting a better understanding of the mdadm situation with this in mind. Things I'd like to know:
 1) I see that mdadm runs its tests/ as autopkgtests. How thorough are those tests? How often are new test cases added by upstream?
 2) How many autopkgtests of other packages are triggered when mdadm is uploaded?
 3) What are the bugfixes (and possibly also new features) that are added between 4.1 and 4.2?
 4) Besides the merit of having many different bugfixes from 4.2, is there a legitimate reason why we want to have mdadm 4.2 in focal? Is there a particular bugfix/feature we need that would otherwise be a pain to cherry-pick? (this is not particularly a requirement, but will help in decision making)

Thanks!

[1] https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases

Hello,
mdadm supports set of different metadata. Intel metadata is a part of it (called IMSM). We (as Intel) are submitted a lot of fixes and features, all are validated and tested. Beside upstream testing, we have our internal test scope, focused on IMSM aspects. I can say with certainty that upstream test form IMSM are working and are used daily.
But there are more metadata types. They are not maintained as IMSM is. There was recent topic on mailing list about problem with tests:
https://<email address hidden>/T/#t

Seems that some tests could be invalid. New test are not added frequently. I'm not aware of CI testing done by the maintainer. For that reason, I have to say that mdadm doesn't meet SRU criteria.

So, according to your questions:
1 - there are some test added a lot time ago and they are not updated frequently. They covers usecases mainly. New test are added rarely.
2- I don't know, but I think that it doesn't matter since it is tending to be rejected.
3- We (and community) submitted many bugfixes for many different problems. There are small improvements, there are fixes for potential DC too. Unfortunately, maintainer doesn't list features in announce file:
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-4.2?id=e30ca260741d727e6f444e8f2ce25fe7a5a26567

4- We submitted many fixes and features for IMSM, all are validated, but as I wrote below- we are only a part of product.

Thank you Mariusz for the explanation. There is a few 'red/yellow flags' here right now, but we can continue the discussion. I mean, some bits we could work-around - like, the lack of a good test automation story - this for instance could be still accepted taking into consideration your (Intel's) testing. Since the only thing we want to accomplish with this requirement is reducing the risk of regressions for existing users, and any thorough testing might be already an acceptable criteria here.

But then I think the remaining requirements for getting this in would be: trying to formulate a legitimate reason (rationale) for bumping mdadm to 4.2 in focal and a list of changes (or at least new features) added between 4.1 and 4.2. If we can get these in order + maybe get some insight into what exact testing you, at Intel, perform on mdadm, we can get the new version into focal-updates.

I assume the most difficult would be the list of feature changes. This is a requirement as we need to know in advance if there's any changes that could potentially break existing users and for us to request additional targeted testing. Maybe we could figure something out here?