[03:14] <JackFrost> sbeattie: ...Would I be able to convince you (or maybe SRU team instead) to accept a point release rather than a targetted commit?  All new features are in master so it's mainly security fixes that get backported to the 7.2 branch.  https://github.com/atheme/atheme/releases/tag/v7.2.12 the buildsystem changes are likely the most painful, but eg the database fix would be nice-to-have too.
=== haggertk_ is now known as haggertk
[10:29] <rbasak> JackFrost: I'm not sure what fixes you're referring to, but if going via the SRU team, the requirements are here: https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
[10:29] <rbasak> You mention buildsystem changes - these will probably be denied in a stable release under that policy.
[10:30] <rbasak> I can't speak for the security team, but usually they will do a cherry-pick only unless security necessitates something else.
[10:38] <JackFrost> Figured, was worth a shot though!
[10:46] <JackFrost> The other fix(es) are nice-to-have, but not part of the security release, strictly speaking.
=== kenyon_ is now known as kenyon
[10:49] <amurray_> JackFrost: we (security) take the same approach as SRU - minimal patches on top of the existing version of a package, rather than a new version (even if it is a micro-version update) - there are exceptions though, same for SRU, so it would depend if a case could be made that it was *less* likely to introduce regressions etc than if backporting a patch