Hi Robie, On Wed, Mar 21, 2018 at 05:02:34PM +0000, Robie Basak wrote: > Dimitri uploaded a dep8 fix for dovecot in bug 1757265.
> I've always been reluctant to accept SRUs for things that are not user > impacting. > For consistency, please could we decide a policy on this? To understand, are you looking for consistency because you think the policy should be to reject autopkgtest-only fixes and you don't want uploaders to shop their upload around to multiple SRU team members to get the answer they want? Or is it that you think it's unfair to uploaders and a waste of their time to have done work that might then be rejected? Or some other reason? > To be clear, this isn't about SRU paperwork. Normally I'd happily accept > a bundled dep8 fix in an SRU with no specific bug for the dep8 fix > itself. I'm asking whether we should accept SRUs to fix this kind of > thing even though there's no actual user impact, instead of asking for > it to be bundled with the next SRU or security fix. My loosely-held view is that autopkgtest-only SRUs are: - not a priority to upload in general - not something I would tend to reject. Particularly for a case of an autopkgtest that has regressed via security/SRU, I think it matters to clean these up, as not doing so means we lose any information about whether *other* SRUs are causing user-affecting regressions in that package. Bundling the autopkgtest fix with the next SRU of dovecot doesn't provide this protection, because the next SRU of systemd (for example) could break dovecot without us noticing because of the ignored already-failing autopkgtests. > Separately, we currently don't have a good place to keep such pending > fixes. We should perhaps define one. Does the Server Team's git importer provide for this as part of the branch schema? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
