=== micahg_ is now known as micahg
=== doko_ is now known as doko
[10:04] <ochosi> if any admins are about, please release libxfce4util from NEW so we (xubuntu) can trigger rebuilds of related packages and continue to upload xfce4.12
[11:51] <mlankhorst> \o/ all mesa regressions from 10.4 to 10.5 on radeon are gone in mesa 10.5 rc3
[12:25] <sil2100> Hello release team! We would need someone to take a look at the FFe that has been filled for the new oxide release: LP: #1425599
[12:25] <ubot93> Launchpad bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599
[14:49] <sil2100> Hello release team! I would like to re-poke regarding the FFe for oxide: LP: #1425599
[14:49] <ubot93> Launchpad bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599
[14:49] <sil2100> It is ready for release in a silo, but we don't know if we can publish without a clear decision beforehand
[16:31] <jdstrand> can someone take a look at the oxide 1.5 FFe? (bug #1425599)
[16:31] <ubot93> bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599
[16:31] <jdstrand> oSoMoN and chrisccoulson can speak to the actual changes
[16:33] <jdstrand> but oxide is in a weird area wrt to this FFe. we plan to push this to stable releases because it is a security update. however, there are some features in it that are for important phone bugs
[16:34] <jdstrand> in other words, oxide was specifically created to address security issues, fix bugs and implement features to enhance the phone (ie, it uses the firefox model), yet it is blocked on FFe
[16:34] <jdstrand> seems we wouldn't block firefox-- we would just upload it
[16:37] <jdstrand> I'm not sure that it helps, but we discussed that we will pursue an MRE for oxide after vivid releases since it is a lot like firefox, and firefox has one
[16:41] <jdstrand> slangasek: not sure if you have time? ^
[16:42]  * jdstrand is happy for anyone to look at it. it looks like it was requested a week and a half ago
[16:44] <ogra_> why does it need an FFe at all ?
[16:44] <ogra_> given it is a rolling package across all releases anyway
[16:54] <jdstrand> ogra_: right
[16:55] <jdstrand> I'm not sure why oSoMoN was advised to file one
[16:55] <jdstrand> I think sil2100 may have requested it, but not sure where this was discussed in terms of formal processes (if at all)
[16:56] <oSoMoN> Mirv initially told me I’d need to file an FFe
[16:57] <sil2100> I wasn't aware of any exceptions, so FFe was the safest bet - and if someone from the release team would comment that we don't need those, well, we wouldn't request it anymore ;)
[16:57] <sil2100> I understand all the rationale, it's just that since it's a release-team decision I wanted to have some confirmation from their side
[16:58] <ogra_> sil2100, well, browsers are generally rolling anyway
[17:01] <jdstrand> right, well, the argument is out there for the release team to comment. we'll pursue a MRE to kinda cement the idea for stable releases
=== adam_g_out is now known as adam_g
[18:07] <infinity> jdstrand: I take it as a given that firefox, chromium, and oxide don't require FFes.
[18:07] <infinity> sil2100: ^
[18:08] <infinity> jdstrand: And the firefox/chromium stable exception (which oxide should get by default, IMO), isn't an MRE, unless you change the meaning of "M". :P
[18:09] <Laney> MyGodWhatIsThis
[18:10] <jdstrand> infinity: great, thanks!
[18:20] <sil2100> infinity: thanks :)
[18:20] <sil2100> jdstrand: ok, let me publish then
[18:20] <Mirv> are the rollingness exceptions documented somewhere?
[18:22] <Mirv> or only as MRE after the release as discussed
[18:25] <Ukikie> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions is the only one I see, and for firefox this is a micro release. :P
[18:26] <Mirv> from documentation point of view the problem is thet MRE are for after-release stable release updates, and it'd be nice if the process would be clear for the whole dev cycle + stable period
[18:35] <infinity> Ukikie: Yeah, we could do with clearing up the browsers as being unique snowflakes in this regard.
[18:36] <infinity> Mirv: And we could also do with clearing up that MREs for stables imply MREs for the devel series, as long as the upload doesn't destabilise the world during release week or something equally silly.
[18:44] <ScottK> Hmmm.
[18:44] <ScottK> For clamav I've always asked for the FFe even though we push major versions to all releases.
[18:45] <ScottK> I took it as a given it would get approved as long as the timing was non-insane, but I didin't think I was excused from asking.
[19:16] <infinity> ScottK: I think it's paperwork overload for things we expect to be updated anyway, but ymmv.
[19:31] <ScottK> OK.  I can accept that and I'm all for not doing unneeded paperwork.
[19:32] <ScottK> I do think we ought to have the list of packages this applies to documented somewhere.
[19:32] <ogra_> +1
[19:44] <infinity> ScottK: Yeah, I think the MRE wiki page needs a section for the rare Major Release Exceptions.  I suspect the reason it doesn't is because we prefer to pretend they don't exist, thus not setting precedent for others to say "I deserve that too!"
[19:44] <infinity> ScottK: But with enough strong wording of the sort that "these packages are unique snowflakes and get to ship new major versions, but if you ask for that for your own package, the TB's default answer is always no, have a nice day", we can break them out into their own section and be more explicit about it.
[19:44] <ScottK> Conveniently keeping the same acronym preserves deniability.
[20:31] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phasing-progress-link/+merge/251517