Re: MRE revoked [Was: Re: MRE request for Bind9]

[Steve Langasek]

On Mon, Jun 05, 2023 at 03:24:43PM -0700, Lena Voytek wrote:
> Since there has been further discussion on the bind9 MRE, I have updated
> the wiki documentation  to reflect
> the additional requirements for this package. In it I added a section
> describing how to avoid changes that may break a user's configuration in
> Ubuntu. I also added searching through releases and marking down these
> changes as a requirement in both the process and the SRU template. If there
> is anything else I should update, please let me know.

Thanks, the main difference is that the uploaders will now be responsible
for reviewing the upstream release notes to check for any documented
backwards-incompatible changes, and report these as part of the SRU process.

That sounds sufficient to me.  New MRE approved.

> On Fri, Apr 14, 2023 at 12:48 PM Robie Basak  wrote:
> 
> > On Fri, Apr 14, 2023 at 12:45:41PM -0700, Steve Langasek wrote:
> > > I'm happy to have that discussion - I just didn't want to leave the MRE
> > in
> > > its current state as a foot-gun to other SRU team members given the
> > > information we currently have.
> >
> > +1 - sorry, I didn't mean to imply otherwise. We should certainly not
> > proceed with any further bind9 microrelease SRUs pending further
> > discussion, so it's entirely correct to have revoked the MRE.
> >
> > --
> > Ubuntu-release mailing list
> > Ubuntu-release@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
> >

> -- 
> Ubuntu-release mailing list
> Ubuntu-release@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-release


-- 
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   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: MRE request for OpenVPN

[Lena Voytek]

Hi Chris,

Thank you for looking into this!

On Thu, Jun 1, 2023 at 5:56 PM Christopher James Halse Rogers <
r...@ubuntu.com> wrote:

> Hi Lena,
>
> Sorry this has taken so long for someone to get to. Review below:
>
> On Mon, Feb 27 2023 at 13:25:25 -0700, Lena Voytek
>  wrote:
> > Hello,
> >
> > I would like to request a Microrelease Exception for the OpenVPN
> > package in Ubuntu Jammy and Focal. I created a wiki page containing
> > relevant information here:
> >
> > https://wiki.ubuntu.com/OpenVPNUpdates
>
> This is a well-written and usefully-detailed MRE process proposal.
>
> My only question to pin down in the proposal would be exactly what
> releases we'll be considering. Certainly releases in the Full stable
> support category; presumably also releases made in old-stable support.
> Would we also be expecting to pull in snapshots in the git-tree-only
> support timeframe under this MRE?
>
The MRE would ideally support full stable and old stable since both support
versioned releases, source tarballs, and provide fixes that may otherwise
not be added by the security team. I think the git-tree only lifecycle
should be ignored unless a relevant bug fix is provided in which case it
should be added through the normal SRU process. I updated the document to
show this.

>
> > Having an MRE would allow us to take advantage of OpenVPN's stable
> > release policy, providing many existing bug fixes to Focal and Jammy,
> > which are using 2.4.x and 2.5.x respectively.
> >
>
> After having a bit of a browse of the 2.6 release branch, I'm not
> entirely happy that OpenVPN's understanding of “stable release”
> matches the SRU policy.
>
> *Most* of the patches on that branch look like either fixes we want or
> changes to code we don't care about (Windows, *BSD, etc), but there's a
> thread of patches to DCO which seem to be feature additions at least
> one of which¹ modifies user-visible behaviour in
> backwards-incompatible ways. This is helpfully called-out in the 2.6.2
> release notes², under “User visible changes”, but this suggests
> that we'll *at least* need a process like the for proposed bind9
> exception where someone explicitly checks the release notes and calls
> out anything that might be a problem.
>
I think this is a reasonable case for checking through release notes and
announcements to see if there are any problematic changes. I've drafted an
additional section, process item, and template item in the document,
similar to my changes to bind9.

>
> The 2.5 release branch looks better in this regard, although a sampling
> there includes a commit³ which includes “Regression warning: shared
> secret setups are left out of the backoff logic.” in the commit
> message (and nothing in the release notes), and at least one new
> feature commit (implementing auth-token-user⁴).
>
Luckily the auth-token-user addition is already in Jammy, but this would
otherwise be a good example of a feature to note for discussion prior to
uploading a new release. This is the same case for connect-retry backoff
modification commit, which does change behavior slightly to fix timeout
issues (bug #1010 ). It
is unfortunate that the note does not show up in the release notes though.
I also don't see any other instances of a regression warning statement in a
commit message in the repository.

>
> I lack the context to decide whether or not these regressions are
> concerning and whether these new features are really bug fixes⁵, but
> with the context I have I'm not sure that a standing MRE for OpenVPN is
> appropriate.
>
> I note that 2.4.x (in Focal) has already dropped out of *all* support
> categories. An SRU to update to Focal to 2.4.12 still might be
> appropriate - the degree of testing, both upstream and in-archive,
> appears good - and that one-off upload would be the only result of this
> MRE for Focal anyway.
>
I agree that Focal should be a one-time upload to get up to date with 2.4.
I've made it more explicit in the document.

>
> It's *also* quite possible that 2.5.9 might be an appropriate SRU for
> Jammy. I'm just not confident (at the moment) that we can delegate the
> “this is an appropriate SRU” decision entirely to OpenVPN upstream,
> which is what a standing MRE effectively is.
>
> > Thank you for considering this request. Please let me know if you need
> > any additional information.
> >
> > Lena Voytek
> >
>
> If there's additional context you can provide that negates my concerns,
> or if you think we can propose a half-way process (like that proposed
> for bind9), feel free to update us.
>
A bind9-adjacent process would probably work well for OpenVPN. If there is
any additional information I should add to the doc to help with this please
let me know.

>
> Chris Halse Rogers
>
> ¹:
>
> https://github.com/OpenVPN/openvpn/commit/321b04fac8d254fe884472109042d8fb83d7
> ²:
>
> https://github.com/OpenVPN/openvpn/commit/3577442530eb7830709538a2e21282b98a97d4f2
> ³:
>