Please lift aging requirement on gce-compute-image-packages in the stable release exception

[Robie Basak]

Hi Balint,

On Thu, Jul 26, 2018 at 11:05:11PM +0800, Balint Reczey wrote:
> Robie Basak pointed out that in the stable release exception [1] for
> gce-compute-image-packages the wording does not explicitly lift the
> requirement for the the package to reach the minimal age (7 days)
> before it can migrate from -proposed to the release.
> 
> In practice requiring 7 days to be spent in -proposed for this source
> package is not particularly useful since the binary packages are
> maintained only for Google's infrastructure and both Google and us
> test them as part of the verification process. No one else is expected
> to test those packages in the remaining time of default required
> minimal age.

Thank you for raising this here. It's certainly undesirable for there to
be ambiguity about whether the aging period applies to this package or
not.

I think your argument could equally be made for any package in the
archive with an interested upstream that performs SRU verification for
us. I don't see any reason here to make an exception just for this
package. Without such a reason, if it makes sense to drop the
requirement for this package, then it follows that it should make equal
sense to change SRU policy to drop the requirement for any package where
an involved upstream with a good track performs SRU verification for us.

I've always seen the aging period as an opportunity for interested
_users_ to nack a proposed SRU that breaks them - for example if their
use case isn't covered by the SRU verification performed by others. I
believe that I have seen this happen in practice. Perhaps not with this
package in particular, but I think the nature of regressions is that it
isn't practical to gather a sufficient sample size looking at a single
package to make this kind of policy decision. One regression is too
many.

In this case, I think user-based regression alert opportunity still
applies. Presumably the reason for this package to exist in the Ubuntu
archive is that there are users. Removing the aging requirement removes
the opportunity for those users to tell us about problems.

My conclusions:

1. In my opinion, there isn't a sufficient justification here (or at
least presented here) to drop the aging requirement for this package.

2. If we do decide to make an exception for this package, we should
consider whether the underlying reason should apply to all packages with
similar workflows by policy, and therefore whether it should be a change
to general policy instead.

3. Removing ambiguity in policy is useful. We should update the SRU
exception documention for this package to make it clear that the aging
requirement still stands.

I welcome opposing opinions from the SRU team.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20180806/cd5ba6cf/attachment.sig>