 "Because that gets staged" <- I missed that (or forgot). What do we need to do?
[08:29] <Saviq> Just rebuild
[08:30] <Saviq> Here: https://launchpad.net/~mir-team/+snap/ubuntu-frame-22-beta
[08:31] <alan_g[m]> Doh! I finally understood what you were saying. Sorry for the noise
[08:32] <Saviq> It's not ideal, but it also does just the minimum (`snapctl is-connected && exec provider-wrapper`) so it shouldn't change _too_ often :)
[08:36] <alan_g[m]> It sounds like reinventing "make" yet again, but maybe we should automate rebuilds when 
[08:36] <alan_g[m]> graphics-core22 changes?
[08:38] <Saviq> Let's see if this bites us again. I don't think it will, any time soon.
[08:40] <alan_g[m]> OK, everything except Frame/22 is promoted to stable: https://discourse.ubuntu.com/t/call-for-testing-ubuntu-frame-mir-test-tools-mir-kiosk-egmde-mir-2-13-0-update/34812/5
[08:44] <alan_g[m]> Still no takers for the cake: Time for "@reviewers ping!"?
[08:47] <Saviq> Yeah, doing.
[10:01] <alan_g[m]> OK, I've updated Frame 22/candidate and tested locally. I'm not going to post a CfT on the forums as anyone using it is already in "here be dragons" territory. Any reason to give CI a chance to complain before pushing to stable?
[10:04] <alan_g[m]> Oh! Right on cue: some test failures! 😬
[10:22] <Saviq> I do see a problem with the test setup - the scripts install stuff with --no-wait and then monitor snap changes for anything Doing. But that doesn't seem to work reliably - possibly the changes are not showing yet when it looks, and then things go wrong down the line
[10:29] <alan_g[m]> So, nothing caused by the snap under test. I'll leave this on candidatee for now. Maybe we'll get the global autoconnect today.
[11:32] <Saviq> > <@github:maunium.net> **[MirServer/ubuntu-frame]** AlanGriffiths opened [issue #135](https://github.com/MirServer/ubuntu-frame/issues/135): We don't label snap versions clearly... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b436c56a5b63145d96ba433ba74bbb82732ce9b9>)
[11:34] <Saviq> Tags have the advantage of a) can do post-factum, b) include annotations; the other approach: c) generally comes in the commit
[11:35] <Saviq> Disadvantages of tags: d) can forget to do post-factum; the other approach e) we'll only be cherry-picking, so the versions will have to mean something different anyway
[11:36] <Saviq> Which sounds to me like we actually need a release process, rather than building from main to beta directly
[11:47] <alan_g[m]> That sounds like overhead we would need to dismantel to get continuous deployment. Can't we automate tagging as part of merge? And then use the tag for building the snap?
[11:48] <Saviq> But what to put in the tag? Like… they're going to mean something different (because cherry-picking), so what more context do they give than the SHA?
[11:52] <alan_g[m]> PR number?
[12:23] <Saviq> If we only allow PRs into core20, yeah that could work
[12:35] <Saviq> Except maybe when we merge more than one PR, but you can still track back to what's in there from the merge commit
[13:02] <alan_g[m]> One "con" is that PRs can arrive in "inverted" order, which might be confusing if anyone is paying attention to the version strings
[13:24] <Saviq> Right, but if we be explicit about it, e.g. 22-pr12+mir2.13.0, then that would hopefully be clear enough?
[13:25] <Saviq> Not sure if we need 22- when Mir version should hint at that, unless someone's stuck on 22 with older Mir for some reason
[13:29] <alan_g[m]> We do need something to avoid tags clashing between tracks, and that's simle
[13:29] <alan_g[m]> *simple
[13:29] <Saviq> They wouldn't ever clash since PRs are linear within a repository
[13:30] <Saviq> But I'm not opposed
[13:31] <alan_g[m]> True. I had been musing about a "cherry-pick and tag" process that tracked the original PR
[13:31] <Saviq> At first I thought auto-tagging as well, but that's just too many tags… would rather extract the PR number from HEAD's commit message
[13:31] <Saviq> And if that fails, something's wrong anyway
[13:32] <Saviq> (fall back to git #)
[13:56] <alan_g[m]> A thought just surfaced, so I'm dumpling it here: would Snap epochs help with moving `latest` to core22 without "breaking" upgrades?
[14:13] <Saviq> Not really, no, the only thing they do is make sure that there is a step when you refresh between epochs directly (e.g. last revision in epoch 1 to first revision in epoch 2)
[14:13] <Saviq> The idea is that you get any migration out of the way in that transition, and don't have to maintain the migration code forever
[14:15] <alan_g[m]> Can't they make epoch 1 stuff invisible to epoch 0 installs? (If we don't create an epoch 1* transition.)
[14:16] <alan_g[m]> Anyway, I was trying to dump and forget. Retrying...
[14:51] <Saviq> That could work… we could even continue to release both epochs to latest… but would have to remember to release 22 last
[15:00] <alan_g[m]> I don't think we want to publish the earlier epoch - in case someone installs it
[15:00] <alan_g[m]> *republish
[15:02] <alan_g[m]> I was simply thinking it avoids suprise migrations
[15:24] <Saviq> Not re-publishing the old epoch would mean they'd be stuck on an old version, and potentially remain vulnerable
[15:26] <alan_g[m]> Yes, they should switch to the 20 track for updates
[15:26] <Saviq> Well, yes, but who's gonna tell them :)
[15:27] <alan_g[m]> I don't think there's a perfect solution, this was just an idea for the mix
[15:31] <alan_g[m]> Folks with a "store" likely don't track `latest` anyway
[16:18] <Saviq> sophie a couple things I thought of wrt. mir-ci:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ef911c2686e3d7999a171d61bfa243c97a4ab6aa>)
[16:24] <sophie-w> pytest marks looks like a good, as long as it it doesn't mess up parameterization
[16:29] <sophie-w> I don't think dependency setup should be part of the tests. For one thing that would make the tests distro-specific. Maybe have multiple setup scripts for different servers? With all the common things installed by one common setup script?
[16:31] <Saviq> Yeah but that explodes… and then to select only a subset of servers / apps, you need to parameterize that…
[16:32] <sophie-w> We could write a script that also respects the MIR_TEST_SERVER variable (or otherwise respects dynamic arguments)
[16:34] <Saviq> Yeah that's what I went for initially, but if using pytest.marks, which I think we should do, we're rid of MIR_TEST_SERVER
[16:34] <Saviq> OK I'll see if I can set it up in a way that the fixture is NOOP (or maybe just checks for [ -x $server ]) unless asked otherwise
[16:40] <sophie-w> I just tested an idea which could maybe solve this? You could have a test that installs the dependencies, but put it in a file that doesn't start with test_. Then you would explicitly run pytest install_deps.py $PYTEST_ARGS before running the tests, and install_deps.py wouldn't automatically run as part of the test suite.
[16:41] <Saviq> Yes, that's exactly what I was thinking
[16:41] <Saviq> And that could still use the same fixtures, only in a "check only" mode
[16:41] <sophie-w> Ok cool, then it doesn't make it any more inconvenient to manually install the dependencies and run the tests on another distro.
[16:42] <Saviq> Or maybe skip mode even better