The SRU team did reach a consensus on this question last July based on
out-of-band discussion (agreeing on option 3 below), but the conclusion had
not been posted to the list and the documentation had not been updated until
now.
Since I am now working on processing an SRU which falls into this
On Fri, Jun 23, 2023 at 10:26:12AM -0700, Steve Langasek wrote:
> Auto-closure of bug tasks was irrelevant to me. We almost never have bug
> tasks open in Launchpad against stable series of packages, *except* when
> they have been opened as part of the SRU process. I didn't even bother to
> look
On Mon, Jun 19, 2023 at 11:33:44AM +0200, Lukasz Zemczak wrote:
> I must say that I was certainly inconsistent in my approach here,
> requesting one of 2) or 3) depending on the particular package in
> mention.
> I'd say that my personal preference would be 2), and this is what I in
> general
For reference, here are the definitions of options 2 and 3:
> >> 2) Reference them normally but then require or expect that the bugs are
> >> verified anyway, even though that's not strictly necessary because of
> >> the agreed QA process as part of the exception.
> >>
> >> 3) Reference them
I must say that I was certainly inconsistent in my approach here,
requesting one of 2) or 3) depending on the particular package in
mention.
I'd say that my personal preference would be 2), and this is what I in
general tried to push for in some cases. If someone decides to
backport a new
On Sat, 17 Jun 2023 at 00:30, Robie Basak wrote:
> In the case of an SRU using some kind of exception to bump to a newer
> upstream version (whether that's a microrelease, a feature changing
> major release or a backport of something) we can end up with:
>
> 1. Some kind of tracking bug that
In the case of an SRU using some kind of exception to bump to a newer
upstream version (whether that's a microrelease, a feature changing
major release or a backport of something) we can end up with:
1. Some kind of tracking bug that explains the exception, for which the
SRU team agrees a QA