Robie asked me for a second opinion on this, so I had a look at it right now. I must say that I'm a bit undecided here, similarly to Robie. But with my SRU-hat on, first thing first: we should not introduce behavior changes that can introduce regressions of existing tools without very solid reasons. So in this case, I only see (b) as an option, but this also depends how the SRU would look like if we added our additional changes on top.
All this seems a bit 'a lot' for a medium-impact bug, especially for an important tool like mdadm. Also, this does fall a bit into the 'feature' category, which is not necessarily disallowed for an SRU, but not something we'd prefer doing without it having a lot of people affected/interested. So my opinion is: let's think about how much this change is needed. If we decide there is more than a few users that would profit from this change, the next step would be to see the final diff with the additional conditional and see if the change is still manageable. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847924 Title: Introduce broken state parsing to mdadm To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1847924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
