[Summary] The timing is very non favorable :-/ Since this is for an LTS release you'd want the new stable upstream version for better HW and general support - but a release date in march is slightly too late. We could file an FFe and get approval there to do it. This won't be ISO content so it can be updated to the final 2.0 version before release without too much hassle.
I'm more concerned about the HW needs. How are we supposed to ever test/verify something. We'd certainly not need every subtype, but at least a bit to be able to work on it. I've asked around but none of the potential teams so far have reported to have nvdimms working with ipmctl (a few requests still wait for an answer). Look at https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1860537 for example. It shows that the truth is even worse as different BIOS revisions and manufacturers create a huge matrix of things that might be hard to support. And it also shows that we can do nothing but wait for an upstream patch, that even then we can't test/validate. Also this isn't a trivial hello-world program. It has portions of UEFI/ACPI handling which can be hard to follow and understand for developers on its own, but even more so if combined without real HW to test things. Just look at this lizard analysis: Total nloc Avg.NLOC AvgCCN Avg.token Fun Cnt Warning cnt Fun Rt nloc Rt -------------------------------------------------------------------------------- 786627 28.4 5.9 162.6 20027 1548 0.08 0.35 Finally in terms of buzzword disambiguation there is Optane DCPMM (nvdimms) and Optane (X-point based nvmes) - of the latter a few exist in the company AFAIK, but not of the former. Yet you have to realize those are different things even though they both carry the same brand name. It just seems to me there are too many uncertainties left right now. IMHO - I'd ask you to revisit promoting it maybe in 20.10 or later. If then things turn out to be super stable and HW exists one could even later consider doing an major version SRU under the Banner of HW enablement. => Yes, more work later, but less risk now. Because vice versa this tooling could just as well live in universe and we can still give it a favor for bug-fixes and CVE tracking, but without the harder commitment of main that we can't make without HW and deeper involvement into the code base. Suggestion: Let us subscribe the server-team without promotion to main for now and later re-consider kicking-off steps to promote it in a later release. As-is: MIR Team Nack [Duplication] No other tool in main already support managing those devices, no duplication. [Dependencies] In terms of further dependencies there are a few, but all of them are already triggered by `ndctl` which we intend to move to main as well. So no extra burden due to these. [Embedded sources and static linking] OK: - no embedded source present that is built into binaries - no static linking in the final binaries created Problems: - there is are snippets of UEFi shells and implementations which partially seem to be copied - at least the build system bundled is duplicated in src:edk2 - it is too vague to make a hard call on it, but it seems reusing a lot of things that might exist (and be maintained) in other places as well - I the mentioned snippets is way too much code (harder to review, harder to maintain). For example some code in BaseTools/Conf will configure static linking. I think that is an artifact from copying things over, but you see my point in this making it harder. [Security] OK: - history of CVEs does not look concerning (but also doesn't exist for too long) - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not parse data formats - does not open a port - does not process arbitrary web content - does not use centralized online accounts - does not integrate arbitrary JavaScript into the desktop - does not deal with system authentication (eg, pam), etc) Problem: - By it's nature it might get to memory in some less-than-usually protected ways/interfaces. That in turn might expose data in some way. The mantra is better safe-than-sorry here so I'd require a security review of ipmctl before being promoted to main. [Common blockers] OK: - does not FTBFS currently - no translation present, but none needed for this case (admin only) - not a python package, no extra constraints to consider int hat regard Problems: - Tests - yes I know this is mostly HW-dependent, but nothing is tested at all. It could at least do unit tests for all the internals and some smoke tests as far as possible in autopkgtests. There are a few indications that tests exist like: ./CMake/unit_test.cmake ./src/os/nvm_api/unittest But none runs at build time. - no Bug subscriber yet, but that is ok as we know it would be the server-team. [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking is in place - d/watch is present and looks ok - Upstream update history is good (just the 2.0 release is at inconvenient times for 20.04) - Debian/Ubuntu update history is good, but has less than 1 year track record - the current release is not packaged, but they release VERY often in beta phase (ok) - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings (See the details reported in the description) - d/rules is rather clean - not using Built-Using [Upstream red flags] OK: - no bad Errors/warnings during the build - no incautious use of malloc/sprintf (as far as I can check it) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH - no use of user nobody - no use of setuid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - not part of the UI for extra checks Problems: - embedded source copies (I mentioned the UEFi/ACPI related copied sources with probably more than needed already above) - Upstream at https://github.com/intel/ipmctl/issues already illustrates that there are quite some bug types that canonical would have a hard time to support. The upstream seems great, but that would probably make us too dependent. ** Changed in: ipmctl (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1854181 Title: [MIR] ipmctl To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1854181/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
