16:02:56 <alebastr[m]> #startmeeting Fedora Sway SIG (2023-01-02)
16:02:56 <zodbot> Meeting started Mon Jan  2 16:02:56 2023 UTC.
16:02:56 <zodbot> This meeting is logged and archived in a public location.
16:02:56 <zodbot> The chair is alebastr[m]. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:02:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:56 <zodbot> The meeting name has been set to 'fedora_sway_sig_(2023-01-02)'
16:03:27 <alebastr[m]> .hello alebastr
16:03:28 <zodbot> alebastr[m]: alebastr 'Aleksei Bavshin' <alebastr89@gmail.com>
16:03:28 <Fale[m]> .hello fale
16:03:30 <zodbot> Fale[m]: fale 'Fabio Alessandro Locati' <me@fale.io>
16:04:10 <defolos> .hello2
16:04:11 <zodbot> defolos: defolos 'Dan Čermák' <dan.cermak@cgc-instruments.com>
16:04:31 <alebastr[m]> don't really have a list of topics for today, but...
16:04:49 <alebastr[m]> #topic Package review for sway-config-fedora
16:05:04 <alebastr[m]> #link https://bugzilla.redhat.com/show_bug.cgi?id=2154941
16:05:17 <Fale[m]> I can pick this up
16:05:52 <alebastr[m]> That would be appreciated
16:05:53 <Fale[m]> #action fale will review rhbz#2154941
16:06:42 <alebastr[m]> our other merge requests are stuck until people are back from vacations
16:06:49 <alebastr[m]> I've seen Jan 09 being mentioned on Infra channel
16:07:06 <Fale[m]> Package Reviews or the ones for the spins?
16:08:00 <alebastr[m]> the ones for spin - fedora-release, kickstarts, comps, etc
16:08:00 <Fale[m]> I have the feeling that until FESCo decision will not be published no merge will occur on those PRs
16:08:16 <Fale[m]> so just after next FESCo meeting, I guess we will start to see momentum
16:08:28 <alebastr[m]> #topic Spin development progress
16:09:23 <alebastr[m]> next fesco meeting is tomorrow, right?
16:09:49 <Fale[m]> yes
16:10:07 <defolos> yes
16:10:38 <Fale[m]> btw: I have a note from Ben pointing out that we have not yet created any PR for the websites and that we shall start working on it
16:11:29 <alebastr[m]> yep. I wanted to set topic to "It's 2023, just a month until code complete and it's time to panic"
16:12:01 <Fale[m]> :-D
16:13:25 <alebastr[m]> I don't understand the current strategy for websites. I think there's a large rework in progress, where SB and Kinoite are moved to the main site.
16:13:40 <alebastr[m]> but it haven't been rolled out yet
16:14:27 <alebastr[m]> #link https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0
16:14:44 <Fale[m]> I think we should do the same we did with the other PRs: assume what is now in the repos is what we should address
16:15:05 <Fale[m]> otherwise we risk to be held hostage of the strategic change to land
16:16:08 <alebastr[m]> ok, then we need a site for Sericea and a download page for classic edition
16:16:14 <Fale[m]> +1
16:16:18 <alebastr[m]> and two (?) docs portals
16:16:21 <jkonecny[m]> .hello jkonecny
16:16:23 <zodbot> jkonecny[m]: jkonecny 'Jiří Konečný' <jkonecny@redhat.com>
16:16:37 <Fale[m]> do spins usually have a docs portal?
16:16:46 <Fale[m]> the rpm-ostree ones yes
16:16:55 <Fale[m]> not sure about the "normal" ones
16:17:17 <alebastr[m]> i3 has, but it's a common location for SIG stuff and some spin docs
16:17:42 <alebastr[m]> https://docs.fedoraproject.org/en-US/i3/
16:18:02 <Fale[m]> makes sense
16:18:34 <alebastr[m]> There are some things we want to document for both classic and ostree (like configuration), but if we can make it work with one docs site that would be better
16:18:40 <Fale[m]> (that's for the sig not the spen, though)
16:18:49 <Fale[m]> *spin
16:20:44 <alebastr[m]> I'll fork SB docs and try to figure out preview pipeline, but anyone wants to take the editing and writing Sericea specific content?
16:21:49 <jkonecny[m]> I guess the best approach is to start from the i3 (content based )
16:22:48 <Fale[m]> if someone creates the repo, I don't mind spending a couple of hours to create a PR to create/improve the content
16:23:18 <alebastr[m]> Thanks!
16:23:38 <alebastr[m]> #action alebastr to set up a repo for docs
16:24:26 <alebastr[m]> #action fale to create Sericea-specific documentation
16:25:25 <alebastr[m]> which would involve removing references to Fedora Workstation, GNOME Software, etc for the first pass of editing :)
16:26:35 <Fale[m]> yeah
16:26:50 <Fale[m]> I think the goal is to have something that is minimally viable first
16:27:01 <Fale[m]> and then over time we can complete/refine it
16:28:09 <jkonecny[m]> I will try to also contribute if possible
16:34:36 <alebastr[m]> hm. https://gitlab.com/groups/fedora/sigs/sway/-/issues is longer than I wanted, and we haven't even started real testing
16:35:58 <alebastr[m]> should we try something like weekly test days? boot rawhide livecd and see what goes wrong with that
16:36:23 <Fale[m]> I think that as soon as we have artifacts from Fedora pipelines we should do that
16:36:40 <defolos> alebastr[m]: that sounds like a job for openqa
16:37:00 <Fale[m]> yes, automating the tests would be sensible
16:37:09 * Fale[m] should start looking in openqa
16:37:24 <alebastr[m]> anthr76 was looking at openqa setup but he seems to be MIA :)
16:37:27 <defolos> I mean that's literally what openQA is good at
16:37:32 <defolos> do you have isos build somewhere?
16:37:48 <defolos> I have tried to plug the i3 spin to openQA years ago, but then never finished it
16:37:48 <alebastr[m]> yes and no :(
16:38:09 <defolos> I could try to make a simple smoke test for sway
16:38:23 <alebastr[m]> we have isos build and published, but the server is not alive
16:38:43 <defolos> but you have the kickstart to build it?
16:39:40 <alebastr[m]> defolos: https://pagure.io/fedora-kickstarts/pull-request/924 or https://gitlab.com/fedora/sigs/sway/fedora-kickstarts
16:40:52 <defolos> alebastr: thanks! I'll take a look
16:41:27 <alebastr[m]> hm. should I switch the sericea publish to quay.io? or make it a backup location
16:42:22 <Fale[m]> I would wait a few days and see if the tickets pick up speed
16:42:58 <Fale[m]> I would prefer to have soon some "officially built" artifacts and remove our own ad-hoc stuff rather than creating more ad-hoc stuff
16:43:21 <alebastr[m]> the whole setup on fedora infra is going to have a very slow roundtrip for testing stuff :(
16:44:24 <alebastr[m]> push changes, wait for compose, wait for repo sync...
16:44:58 <Fale[m]> true, but I don't think have a parallel infra (ie: maintain double scripts etc) will help us in the long term
16:45:24 <defolos> also, there will be probably very few changes after an initial period where everything is in flux
16:45:50 <alebastr[m]> yep, we should move things over there as much as possible. but at least workstation-ostree-config fork with nightly builds of configs is useful
16:45:52 <defolos> we have worked around this in i3 by someone building a testimage ad hoc and then uploading it as a file on Telegram 🙈
16:47:38 <alebastr[m]> besides, we can't run the rawhide ostree from the official infra, right?
16:48:06 <Fale[m]> why not?
16:49:17 <Fale[m]> in my list of possible remotes I see for instance fedora:fedora/rawhide/x86_64/kinoite
16:49:26 <alebastr[m]> is it even stable enough for daily use?
16:49:36 <Fale[m]> that's a different question :-D
16:49:57 <alebastr[m]> well, I guess we should make an effort to keep it stable
16:51:21 <Fale[m]> speaking of which, I think we should create an internal "rule" not to upgrade sway on released branches and to create Fedora changes for new sway versions, so that it also ends up in the fedora release notes
16:52:41 <alebastr[m]> We've been following that rule since the beginning, right? Although creating Fedora changes seems too much.
16:53:23 <Fale[m]> if we want to give visibility to the change, we need to
16:57:03 <alebastr[m]> Fale: I would prefer to give more visibility to our updates policy :)
16:57:40 <alebastr[m]> but here's the thing: I was expecting Sway 1.8 in f37 timeframe. it was promised to release last summer, after all
16:58:01 <Fale[m]> Phoronix and the others look at changes more than policies ;-)
16:59:28 <alebastr[m]> but wlroots/sway development team uses 'when it's done' release schedule so we'll have to deal with changes being moved to the next release
16:59:40 <alebastr[m]> every time :)
17:00:41 <jkonecny[m]> the issue with this is use pre-released parts on Rawhide and then change that for branched Fedora
17:00:55 <jkonecny[m]> we want pre-release parts on Rawhide though
17:01:26 <alebastr[m]> we don't want nightly builds on rawhide
17:01:40 <alebastr[m]> and pre-release means that the release will be in 4-5 weeks
17:02:08 <jkonecny[m]> 👍️
17:02:10 <alebastr[m]> not enough to go through the whole change process, esp. if it happens late during the release cycle
17:03:09 <jkonecny[m]> <Fale[m]> "true, but I don't think have a..." <- +1 for not having our internal infra. For package testing you can always overlay koji/copr build package to Sericea
17:03:55 <alebastr[m]> Fale: I'd agree with the wording "make an effort to announce the update via self-contained change if the release schedule permits"
17:06:56 <alebastr[m]> hm. but if we want that for release notes, can we short-circuit the process?
17:12:34 <alebastr[m]> #topic Open Floor
17:12:47 <alebastr[m]> any remaining topics to discuss?
17:13:53 <defolos> just one thing
17:14:01 <defolos> do you have instructions somewhere how to build the iso from the repo on gitlab?
17:15:23 <jkonecny[m]> https://gitlab.com/fedora/sigs/sway/fedora-kickstarts/-/issues/1
17:15:37 <defolos> Thanks jkonecny !
17:15:46 <alebastr[m]> defolos: .gitlab-ci.yml should also have all the steps
17:16:15 <alebastr[m]> I wonder if there's a tool that can run these locally, like act for github
17:16:27 <jkonecny[m]> this don't have commands for Sericea only for Live media
17:17:53 <alebastr[m]> I wanted to bring up <https://src.fedoraproject.org/rpms/sway/pull-request/13> again
17:19:22 <alebastr[m]> it appears that some EGL code in wlroots would need CAP_SYS_NICE to work, and we can't work around that with rtkit
17:20:14 <alebastr[m]> I wonder if it's important enough to set the capability by default
17:27:08 <jkonecny[m]> Sorry but I can't help much here ☹️.
17:29:50 <alebastr[m]> Then that's it for today. I'm going to close the meeting
17:30:21 <alebastr[m]> #endmeeting