Comment 37 for bug 1621507

I'm here processing open-scsi in the Xenial and Yakkety SRU queues. However, I feel that this SRU is far from ready to be accepted into the proposed pockets and am inclined to reject the uploads to prevent further confusion.

1) Stakeholders don't appear to have consensus on how this problem should be fixed. Can you figure this out amongst yourselves before uploading? If you end up at an impasse, I'd appreciate a description and clarity on what the impasse is exactly to help the SRU team (or the TB if Zesty I guess) make a decision.

2) Given that the first attempt has regressed stable releases already and had to be backed out, I'd expect more effort to bake this in the development release first, rather than throwing it at stable releases at the same time.

3) I expect the "Test Case" and "Regression Potential" paperwork to make reference to the regression that has already hit the updates pocket, with a test plan to stop that sort of thing happening again, but these sections don't appear to have been touched.

4) open-iscsi, which is in the upload queue for Xenial and Yakkety, doesn't currently have its development task marked Fix Released and I see no explanation for this. I see that this is likely due to a dep8 failure blocking proposed migration. But given point 2, perhaps we shouldn't ignore that as it might be hiding a real failure?

5) It may be that the open-iscsi change itself is uncontroversial and that's why it is uploaded without the others. But if we did accept open-iscsi into proposed, then we'd end up with a verification-needed tag, which might soon turn into verification-done. If we then end up accepting initramfs-tools or isc-dhcp, then we may end up racing the tags, causing confusion and accidental release of an proposed update that has not been verified. I'd like to confirm with a more experienced SRU team member whether this could actually happen, but it seems to me that given the complexity of this SRU it would make more sense to first get consensus on all the changes intended to be landed to fix this issue, land everything into proposed at once, verify them both individually and functionally all together while they are all in proposed together, and then release them all together to the updates pocket. Doing them piecemeal doesn't make much sense to me, and I feel increases regression risk. Additionally one update could end up insufficient as you debate and change the approach, in which case we'd need an additional SRU (and risk another regression, etc) for no good reason.