On Thu, Mar 22, 2018 at 10:04:11AM +0000, Robie Basak wrote: > > > 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? > I think consistency saves wasting everyone's time, so all of the above. > Uploaders would know what to expect and SRU team mebmers won't duplicate > review time. It would a waste for me to reject or defer an SRU and for > another SRU team member to later accept it, and frustrating for > uploaders to be playing a lottery like that. I agree that this would be wasteful. I'm not sure it comes up often enough that we would be saving energy by attempting to (agree on and) adopt a hard policy, however. My own view is that for the specific narrow case of a package whose autopkgtests have regressed post-release, and there are dependencies of that package being SRUed, and there is an Ubuntu developer who cares enough about the regressed package to prepare an upload a fix, it is reasonable to accept an SRU for this. I'm interested to hear the opinion of other members of the SRU team as well. -- 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
