13:31 <seb128> #startmeeting Desktop Team Weekly Meeting - 2020-09-22 13:31 <meetingology> Meeting started Tue Sep 22 13:31:11 2020 UTC. The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 13:31 <meetingology> 13:31 <meetingology> Available commands: action commands idea info link nick 13:31 <seb128> Roll call: didrocks, duflu, hellsworth, jamesh, jibel, kenvandine, Laney, marcustomlinson, oSoMoN, seb128 , tkamppeter, Trevinho, robert_ancell, callmepk 13:31 <Trevinho> o/ 13:31 <oSoMoN> o/ 13:31 <marcustomlinson> \o 13:31 <didrocks> o/ 13:31 <luna_> o/ 13:31 <callmepk> o/ 13:31 <hellsworth> \o 13:32 <seb128> k, let's get started! 13:32 <seb128> #topic rls-bb-bug 13:32 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html 13:32 <seb128> no desktop entry 13:32 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html 13:33 <seb128> bug #1801814 13:33 <ubot5> bug 1801814 in flatpak (Ubuntu Bionic) "Environment overwrites XDG_DATA_DIRS" [Undecided,Confirmed] https://launchpad.net/bugs/1801814 13:33 <luna_> seems a fix is released in Focal? can that be backported? (just a question) 13:34 <seb128> it could probably 13:34 <seb128> it's a flatpak/wayland session fix on bionic 13:35 <seb128> I think it's not a priority to target for us, since it has no assign I would suggest deleting the bionic target for now 13:35 <seb128> it doesn't stop someone to work on it if they want 13:35 <didrocks> agreed 13:35 <seb128> thanks Didier, deleted 13:35 <seb128> and that's it for bionic 13:36 <seb128> #topic rls-ff-bug 13:36 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html 13:36 <seb128> the one bug there is assigned and targetted but just not untagged 13:37 <seb128> remind me that I said I would try one day to filter those cases out of the reports, I will put that for my next hacking session 13:37 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html 13:38 <seb128> Trevinho, you forgot to assign the SRU bug to yourself 13:38 <seb128> other items are assigned or incomplete 13:38 <Trevinho> seb128: oh 13:38 <seb128> #topic rls-gg-bug 13:38 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html 13:38 <seb128> no desktop entry 13:38 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-tracking-bug-tasks.html 13:39 <seb128> nothing needed there 13:39 <seb128> #topic update_excuses_by_team.html#desktop-packages 13:39 <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages 13:40 <seb128> gstreamer is being hanlded 13:40 <luna_> There is a new Firefox 81, and Thunderbird (some version) released today and yesterday if oSoMoN wants something new to package up btw :) 13:40 <seb128> gnome-control-center should clear off when retries results are updated 13:41 <seb128> luna_, thanks, such comments are better for the AOB part of the meeting that come next :-) 13:41 <seb128> glib/gst-omx sounds like something that needs investigated 13:41 <seb128> any taker? 13:41 <Laney> I already handled it 13:41 <seb128> great 13:41 <seb128> gnoe-shell Binaries broken by the update: gnome-shell-extensions/3.37.91-1~fakesync/amd64 13:42 <seb128> Trevinho, ^ you are handling that? 13:42 <Laney> Handled 13:42 <Trevinho> sync to be done 13:42 <luna_> seb128: alright then i know that for next time 13:42 <seb128> shell is what is blocking xdg portals, etc (I've a mp for the report script that would indicate that if someone wants to review it ;-) 13:42 <seb128> k, then we are good 13:42 <seb128> #topic AOB 13:42 <seb128> any other topic? 13:42 <Laney> It's not to be done, I fake synced it 13:42 <Laney> yeah 13:43 <Laney> the SRU team are asking about the scope of our micro release exception 13:43 <Laney> looks like life is going to get harder for gnome shell updates, around extensions 13:43 <seb128> I saw that on discourse 13:43 <Laney> https://discourse.ubuntu.com/t/scope-of-gnome-mru/18041/ 13:44 <seb128> Trevinho was reprsenting us well there I think 13:44 <Trevinho> yeah, doesn't make much sense imho, we need to figure out a way not to be blocked by them 13:44 <seb128> I wonder if we should just remove any extension .deb from the ubuntu archive 13:44 <Trevinho> it's very hard to check ALL them, not sure if we can avoid debian syncs for them at all 13:44 <seb128> and tell users to just use the upstream facilities to install those 13:44 <seb128> (I mean the ones we are not relying on and testing) 13:44 <Trevinho> I'd agree, we can just support our ones, for the rest packages don't make any sense IMHO. 13:44 <oSoMoN> I was going to suggest deleting extensions that are known offenders 13:45 <Laney> If that's what the SRU team wants 13:45 <Laney> then fine, let's kick all gnome-shell-extension-* out 13:45 <seb128> that should maybe a suggestion someone (Trevinho?) should post about on discourse to have a public discussion ? 13:45 <Trevinho> seb128: is it possible to avoid auto-syncs to apply tho those packages? 13:45 <luna_> https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/ is this in anyway helpful or related? 13:45 <seb128> it's possible to blacklist syncs yes 13:45 <Trevinho> I feel alone in that discussion, so if someone joins me, at least I don't feel like I speak for myself only :D 13:46 <didrocks> agreed that it’s the only sustainable way for us due to API instability IMHO 13:46 <seb128> I don't know if you can do gnome-shell-extensions* 13:46 <Laney> it's just code, it can be changed to do anything 13:46 <Trevinho> ther's basically NO api either :) 13:46 <Trevinho> we've a volounteer :D 13:47 <seb128> Trevinho, can you post on discourse saying we want to remove those because of SRU requirement and upstream minor versions not being compatible 13:47 <seb128> I will create a trello card 13:47 <Trevinho> ok 13:47 <seb128> and I will reply on the SRU team discussion, sorry for not doing earlier 13:48 <seb128> I though you were handling that well so stayed out of it :-) 13:48 <Trevinho> eheeh, no worries :) 13:48 <Laney> Is this all because of one bug that happened once, or are there other cases? 13:48 <Trevinho> thanks then 13:49 <Trevinho> I've given my opinion on packages we still need the exceptions for, but maybe that list could be improved, so maybe it's better if you guys review it again and propose a final one (I'm sure Laney wanted something more) 13:49 <seb128> Laney, I will let Trevinho comment on that, maybe a good question/answer for the discourse topic 13:49 <seb128> Trevinho, right 13:49 <Trevinho> Laney: not that I know, but for sure may be... there could be loads of cases where it's not working, just nobody checks 13:49 <seb128> we can discuss that more after the meeting if needed 13:49 <seb128> any other topic ? 13:49 <Laney> The point for SRUs though ... 13:49 <Laney> ok 13:50 <Trevinho> well this is still something for all the team I imagine, so... fine to skip to later, but it should be interesting for most of us 13:50 <seb128> Laney, sorry I though we addressed the SRU question enough, anything specific you think we should cover here? 13:51 <seb128> Trevinho, 'this'? 13:51 <Trevinho> SRU thingy 13:51 <Laney> yes I was just going to say that SRUs don't care if something is working in the archive or not, it's more if something is broken *by* the SRU 13:51 <seb128> if I understand the request we need to review the discourse post and see if the list makes sense and is complete 13:51 <seb128> and agree on a course of actions for extensions 13:51 <Laney> it's "OK" for things to be broken and stay broken 13:51 <Trevinho> > In that case, I think this means that we cannot push microrelease updates of gnome-shell to stable releases because such updates are known to break packaged extensions. The microrelease exception was originally granted by the technical board on the basis that such updates are not expected to break things, and that situation has clearly changed in the case of gnome-shell. 13:51 <Trevinho> just arrived a reply.... 13:52 <Laney> so I think the scope is about whether shell stable releases do actually break extensions or if this is just one 13:53 <seb128> I've a feeling the SRU team is not going let us get away with a 'this is one' 13:53 <seb128> reality is that it can happen 13:53 <kenvandine> yeah, it can 13:53 <seb128> so we either need to remove things from the archive to reduce our testing 13:53 <seb128> or increase our testplan to cover what is in the archive 13:53 <Trevinho> can we remove things from focal though? 13:53 <seb128> or another option I'm not thinking of? 13:53 <seb128> I don't think so 13:54 <Trevinho> I've NOT a scientific way to check if we're breaking 13:54 <seb128> but we shouldn't have more new tarballs for focal after that round 13:54 <Trevinho> nor saying "I teated them all" i think would be professional 13:54 <Trevinho> tested* 13:54 <seb128> GNOME schedules stops at .6 13:54 <Trevinho> yeah, but... we can still do cherry-picks 13:54 <seb128> so I say we do an effort to test extensions from the archive for that round if that's what the SRU team requires... 13:55 <Trevinho> and they may happen (like OEM things, for example I may do in the fingerprint lands) 13:55 <seb128> well then we need to convince the SRU team on those cases that it's fine 13:55 <seb128> either by explaining why the changes cherry picked are not risky 13:55 <seb128> or by testing the extensions... 13:55 <seb128> no? 13:56 <Trevinho> 41 extensions, not easy task 13:57 <Trevinho> sorry 42 in focal 13:57 <Trevinho> let's remove the 3 we handle.... still 39 to check, impossible. 13:57 <seb128> not impossible, but expensive to do yes 13:58 <luna_> would it not be easier to let people download the extensions they want from: https://extensions.gnome.org/ ? 13:58 <seb128> luna_, that's basically whar we suggested doing going forward 13:58 <seb128> but we can't change past releases 13:58 <luna_> ah true 13:59 <seb128> anyway 13:59 <seb128> I'm a bit lost at this point 13:59 <seb128> Laney, Trevinho , did you want to get some conclusion out of the meeting? 13:59 <seb128> or should we just wrap and keep that going here if needed? 14:00 <Laney> it would have been nice to have had a unified position as the team 14:00 <Laney> but it's ok, I guess that isn't going to come from a quick chat in the meeting 14:00 <seb128> right, I think we need some data and time to process which is why I was suggesting Trevinho start a discourse topic about his proposal of removing extensions 14:00 <Trevinho> yeah, not sure... I would like to have a statement to reply for sure 14:00 <seb128> we can continue the discussion there 14:01 <Trevinho> given the new one I mean 14:01 <seb128> Trevinho, I'm going to reply 14:01 <seb128> to the SRU post on discourse 14:01 <Trevinho> seb128: new topic, not same on SRU exceptions, right? 14:01 <seb128> yes 14:01 <seb128> one specific about removing deb extensions for better shell maintainability 14:02 <Laney> Robie asked for that conversation to be with the release team 14:02 <seb128> they are on discourse? 14:03 <Laney> Not sure, there's a category there but we only used it for like release schedules so far 14:03 <seb128> k, I'm going to read the SRU post again there now 14:03 <seb128> but no point keeping everyone in the meeting for that imho 14:04 <seb128> so let's wrap and those interested can continue the discussion 14:04 <kenvandine> ok 14:05 <seb128> #endmeeting