[16:49:53] Meeting started by itchka [16:50:25] Current subject: 2: Release of 4.2 progress and testing (set by itchka) [16:51:45] I guess the question here is how long do we allow for testing and bug fixing. We really do want to get rolling off the ground this time around [16:51:55] There should be more testing than there was for 4.1. [16:53:09] to be fair 4.1 got rushed in getting release ready for fosdem [16:54:33] bero: How long before there are any more Qt/kde updates? [16:55:43] It seems like from time final ISO is built we need about a week to do thorough testing and get all release tasks done. [16:56:03] https://community.kde.org/Schedules/Plasma_5 [16:56:22] https://wiki.qt.io/Qt_5.15_Release [16:56:35] So we have qt 5.15 final expected in mid-May [16:56:53] I'd suppose we want to follow usual release cycle pattern (alpha, beta, RC, GA) for 4.2.. or not? [16:57:08] Plasma 5.19 in early June [16:57:13] rugyada: yes, I'd say so [16:57:15] So we don't need to rush this them. [16:57:29] bero: ok [16:57:35] No, I don't think we should release before Qt 5.15 final is out... [16:57:57] Shipping a final release with a beta version of a key library, even one that works well, is a little odd [16:58:03] That long? [16:58:41] I thought we wanted to get theis out quickly [16:59:30] quick is not always the best option :) [17:00:56] bero I need help with mozjs68, this is blocker for few packages [17:02:21] AngryPenguin: what's up with it? [17:02:37] itchka: that's quite quick compared to how long we usually take for releases... [17:02:51] If we release along with Plasma 5.19, that would put 4.2 about 3 months after 4.1 [17:03:11] 4 actually, FOSDEM was at the beginning of February [17:04:33] Given the grizzling about the 4.1 release I thought the general feeling was get get something new out fairly quickly [17:05:20] we may want to take a few more time for testing new plasma then [17:05:28] we can do a 4.1.1 release too... [17:06:02] rugyada: plasma has a long beta cycle too, so if we go with all the alpha/beta/rc releases there, we've had plenty of time to test it [17:06:32] I'd like to release quickly after (if not along with) the plasma release to get the attention of people who want the new plasma [17:06:39] Maybe that is what we should do. Otherwise rolling will have to remain static for a longish period which kind of defeats the object of it. [17:06:42] if brokenbuntu has it first, that won't help us... [17:06:53] ok [17:09:05] so looks like we are going back to 4.1.1 project suggestion [17:09:18] as quick release :) [17:10:08] and make itchka happy again [17:12:28] so if we are going to do 4.1.1 we need to decide which of the negative comments from reviewers we want to and can fix? [17:14:09] ben79: I think the fixes were all already scheduled when not already in place [17:15:01] they have issued a review more than one month later [17:15:23] We have time to properly stabilise rolling before huge amounts of stuff start getting thrown at cooker again. Can we please be disciplined this time around and make sure the core is bug free [17:15:52] I don't pay much attention to Linux os reviewers, never have, so I don't really know, it just seemed like from following conversation that is the reason for a 4.1.1 release. [17:16:24] ben79: you know 4.1.1 was planned since a lot of time [17:16:58] just we could not do it as quick as we wanted [17:18:17] no I did not know it was planned, I don't recall we ever decided, we keep going back and forth are we going to do 4.2 or 4.1.1 [17:18:56] ben79: yes it was :) [17:19:15] OK, to me it never seemed definite [17:19:44] but ok, not too much important right now [17:20:11] more important imo is to decide and act [17:20:25] for one thing we ought to be able to list what we are changing and I never have seen that [17:20:36] right [17:20:58] I'll I've heard is nebulous comments about reviewers, [17:21:50] This would be so much easier if we had a project board and kept it up to date... [17:22:01] ben79: WIP [17:23:14] what provide dbus-run-session? [17:23:59] osmosis [17:24:17] :D [17:24:57] no :) [17:24:58] That was a bit salty :) [17:25:38] I guess it is significant that we have gotten some negative reviews though, since Linux OS reviewers tend to be stupidly positive [17:26:07] well I only meant humorous [17:27:10] Right lets gets a timescale for this '4.1.1' release. Is 2 weeks sufficient to freeze rolling and bug fix. [17:28:19] abf-downloads is diabolically slow [17:28:53] 2 week freeze would be historic [17:29:11] never happened and never will [17:29:14] That's why it's such a good isea :) [17:29:18] idea [17:29:30] with 4.1 we were still adding stuff the day before... [17:29:53] ben79: I'd say the same day [17:30:06] Which is why the realease was'nt all that good perhaps? [17:30:15] yes [17:30:27] testing for 4.1 was weak [17:30:46] a lot just did not get tested [17:31:07] There's other stuff that needs to be done it that time; synching the mirrors for one. [17:31:11] yes but we discovered some kind of issue just later and had to make last-seconds fixes [17:31:49] itchka: mirrors is topic apart [17:32:13] rugyada: If we are to do a release we will need working mirrors [17:32:22] which would be better to fix asap [17:32:30] I would have said if you are going to release something for FOSDEM you stop adding new packages about a week before myself... or delay the release. [17:33:12] rugyada: That is exactly what I meant [17:33:21] itchka: yes [17:33:25] but we had set an impossible set of condidtions for ourselves we have to have such and such and that was not released until a day or two before fosdem [17:34:42] looks like it's going to take about a wekk tobuild a local ABF-1 iso :) [17:34:46] anyway we don't have to do that for 4.1.1 or 4.2 so let's don't [17:34:54] itchka: ben79 @everyone: practice will make us perfect [17:35:05] it hasn't yet [17:35:15] maybe some day... [17:35:26] ben79: think positive [17:36:04] so [17:36:22] bero: your last word re 4.1.1 ? [17:36:27] QA keeps saying for better releases at some point we need to stop, and freeze things, and allow for thorough testing. [17:37:09] That means thorough testing of exactly what we are going to release. [17:38:12] ben79: it would be good and sane [17:38:58] practice won't make us better if we continue to practice the same mistakes [17:39:21] ben79: lol - and agree [17:39:52] otherwise I'm 110% in agreement with the statement [17:40:20] at least we try... [17:41:09] devs are undisciplinate thou :D [17:41:21] I believe itchka and I are trying to get some focus and commitment on how much QA do we want for 4.1.1? I asked for 1 week, itchka asked for 2 weeks, if there are any bugs at all 2 weeks is more workable [17:42:44] 2 weeks? in 2 weeks they will remake the distro from scratch :P [17:42:48] If we allow two qeeksa we can always cut it short if we are happy with what we have. [17:43:39] Well either we want to avoid the problems we have with 4.1 or we don't [17:44:04] If we don't just cp cooker2rolling and release in 3 days [17:44:48] bero: Is cpcooker2rolling in progress? [17:44:54] me is in joking mode today.. [17:44:59] If we do that means we want better QA which, gasp, cough, means actually listening to what QA is saying [17:44:59] back, just getting off the phone with a headhunter [17:45:01] reading back [17:45:39] * [17:45:55] re 4.1, one thing to keep in mind is that almost none of the things reviewers are screaming about were caused by last minute updates [17:46:09] Meeting chairs are: bero, itchka [17:46:32] no they were mostly caused by lack of testing, [17:47:01] If we do 4.1.1, it should probably be based on the 4.1 branch rather than rolling/cooker because of the huge toolchain changes that have already happened... [17:47:08] but because of last minute changes we never were settled on what we were supposed to test [17:47:47] cooker2rolling hasn't started yet, still waiting for the qtwebengine build to finish [17:48:01] I would think 4.1.1 has to be based on 4.1 with whatever we decide we want to fix [17:48:21] 4.1 branch that's sure [17:48:27] https://abf.openmandriva.org/build_lists/726978 [17:48:33] https://abf.openmandriva.org/build_lists/726979 [17:48:34] which is why we need to decide what do we want to fix [17:48:39] https://abf.openmandriva.org/build_lists/726981 [17:48:46] https://abf.openmandriva.org/build_lists/726982 [17:49:02] some reviewer complaints are valid and some are bs [17:49:31] bero I sync mozjs68 with 60 (patches etc) and update but most of patches need to be dropped or rebased [17:49:39] not sure how to deal with it [17:49:47] looking [17:52:05] It *may* mean that people here need to spend more time with and in Lx 4.1 in order to know what is going on with it and what really needs fixing, most everyone here is way more focused on cooker than 4.1 [17:52:19] true [17:52:20] Including you know who [17:52:23] I don't have any 4.1 boxes anymore [17:52:26] me [17:54:28] So reason I keep asking what we want to fix for Lx 4.1.1 is that I don't know what we need to fix myself. [17:55:24] I don't know either [17:55:35] worked well for me, but doesn't seem to be working for anyone else [17:56:17] imho in the ideal world at time of release we redirect the (few) resources: freeze and everyone including devs want to test what we are going to release [17:57:04] that would be what I consider normal QA, [17:57:05] 1 week deep testing is not such a big sacrifice [17:58:36] rugyada: 2 weeks of freeze and testing in which only bug fixes are allowed and that include all branches before an release [17:59:37] most of the time the bug in 'to-be-released' branch exist in cooker etc , [18:00:21] crazy: yes [18:00:24] I do have partitions with Lx 4.1 but currently I spend most of my time in Cooker because that is the only opportunity we have for package testing at present. [18:00:30] if you now go ahead and throw crap in cooker before an release QA gets weird, you need QA against branch and bugs may remain unfixed in cooker [18:00:58] even if 2 weeks freeze may be difficult to get [18:01:20] rugyada: why is 2 weeks difficult ? [18:01:31] It's not difficult if everything is branched properly [18:01:40] bero: yes [18:01:46] We would be talking about freezing Rolling not Cooker so I thing we should be able to do that, [18:01:53] it's just against devs' DNA [18:02:18] find bug, fix in cooker , build for cooker & branch, next issue etc [18:02:22] That's what cooker is there for [18:02:51] bero: even cooker has to be just-bug-fix before releases [18:03:19] Obviously we can freeze Rolling because it kind of is frozen right now and has been for weeks [18:03:22] after that throw shit in it no one cares , is meant to breka again until next release [18:04:00] ben79: before an release except old-stable all branches are the same [18:04:18] ben79: so full-freeze for xxx days / x weeks and fix issues [18:04:36] you can go cooker -> merge fix in both , next issue etc [18:04:58] if you are in sync all QA / fixing should be better , faster and not complicated at all [18:05:23] I'm just saying that the issue is not that we can't do a freeze the issue is that we could and we don't [18:05:34] ben79: yes [18:06:04] IMO no one will die if cooker don't see some new rc for 2 weeks :-) [18:06:22] QA gets over ruled by developers that just have to get in before release, it never ends [18:06:56] but usually that's because fixes more bugs than it introduces [18:07:23] if there's an upstream release that has 500 bugfixes and 1 new feature, it's pretty clear that it should go in [18:07:41] yes, full understandable. [18:07:45] if there's an upstream release that has 500 new features and 1 bugfix, probably it's better to backport the bugfix [18:07:52] bero: sure that is not the issue the issue for me is the desync before release , no-one can really tell what is fixed and what not [18:08:03] developers always say that, but to to QA you have to stop at some point and to QA [18:08:06] crazy: agreed [18:08:46] and do QA [18:09:20] bero: now say we fix 30 bugs in branch , cooker throws some shit in and is broken for weeks , no-one can even verfy if the bugs still exists , and no one will ever remeber what to do 4 weeks later [18:09:29] solution is: after this big bugfixing the freeze starts again [18:09:45] rugyada: no [18:09:48] I have to go and cook. bero you are a chair I'll add ben79 too just in case [18:09:55] rugyada: the freeze is meant to bugfix [18:10:06] Meeting chairs are: bero, itchka, ben79 [18:10:30] crazy: you can't test the bugfix if you don't have the time to do [18:11:11] rugyada: sure, but you cannot loop forver , there will be always bugs of some sort [18:11:13] If the freeze is meant to bugfix we need to clarify if we are talking about fixing identified by OM bugs or "plasma release includes 150 bug fixes" even though in OM we have not identified a single bug. [18:11:19] ofc there is difference between small bugfix and big bugfix [18:12:04] ben79: we talk about fixing bugs in the packages exists and are ment to be released [18:12:47] ben79: the rule should be , like bero said , if there is the need to bump any package then only bunp if sure i fixes more that it breaks if not backport the fix you need [18:13:10] crazy: that is what we *should* do not what we have been doing [18:13:25] ben79: yepp I know, just saying lol [18:15:06] So we need 2 weeks from freeze to release for bug fixing and other tasks, unless a bug fix requires major changes or tool-chain change which means add more time [18:15:31] add more time if we think is necessary might be better way to say [18:15:56] But bug fixing needs to mean just that bug fixing [18:16:42] our bugs not bugs someone upstream thinks are bugs [18:17:16] sure, but most bugs found upstream are just ones we haven't found yet [18:18:23] but that will lead to the circle we already have dev "we have to get this in" qa "we need to stop and test exactly what we are going to release" rinse and repeat [18:21:58] I keep saying if there are upstream releases that fix bugs there is no reason that can't go in normal system updates we don't have to get absolutely everything in an ISO [18:22:46] And for QA to do it's job we need to be able to test exactly, not mostly or almost, exactly what we are going to release. [18:23:09] When devs keep adding packages QA thinks we have to start testing over, because that is proper QA [18:23:40] That is what we are supposed to do. [18:26:10] sure [18:26:33] anything that can be done can be overdone, on both sides of the issue [18:26:50] Yes [18:26:58] e.g. if an update brings in more features than bugfixes it usually shouldn't go in [18:27:26] but OTOH if let's say falkon is updated for whatever reason, that doesn't mean testing of command line tools has to be restarted [18:27:49] I would say we could simplify this process if we did have formal freezes and if we required and changes to be justified as bug fixes. [18:28:58] agreed about that [18:29:06] What you say about falkon is true to an extent, but it is also true that there can be and are unintended consequences and Murphy's law which QA has to consider. [18:29:41] that is why qa peoples tend to be so insistent on "we need to test exactly what we are going to release" [18:31:11] If we did a formal freeze when we do bugfixes we should perhaps include a discussion of what needs to be tested but keep in mind the qa people consider "assume" to mean you make and ass out of u and me. [18:33:55] but generally I'd say if we upgraded falkon or other such app for a bug fix we would test that application to be sure the bug was fixed not go back and test everything. [18:34:26] If we did a major upgrade for bug fixes like plasma desktop or kframeworks obviously that is different [18:34:56] tool-chain upgrades during freeze generally would mean start testing everything again [18:35:28] bero ben79 I agree that freeze is necessary but I see no reason to do freeze in cooker [18:35:35] anyway lets go next item [18:35:55] where is the list of items? [18:36:04] is there a list? [18:36:13] 17:07] Here's a provisional one. [18:36:14] [17:07] 1: Cooker Report [18:36:16] [17:08] 2: Release of 4.2 progress and testing [18:36:17] [17:08] 3: Music Apps [18:36:19] [17:08] 4: AIB [18:36:20] [17:08] 5: AOB [18:36:39] so we would be at 3? [18:36:47] .topic music apps [18:37:03] well bleep you too [18:37:17] xD [18:37:23] you are not a real dog [18:38:40] ben79: should work now, but let's not forget topic 2A [18:39:06] [17:10:44] I'd like to add: What, if anything, do we need to do because of all the bad reviews [18:39:06] [17:10:54] Some have a few valid points [18:39:06] [17:11:20] Ok I'll add that as 2A [18:39:40] #topic evil reviews [18:40:04] .topic what to do about negative reviews [18:40:32] There's a few things in them that are probably right... [18:41:03] we should probably fix the website and make sure stuff like om-welcome doesn't link to pages that don't exist anymore... [18:41:33] and when redesigning the website or something, need to make sure that links in welcome and friends are updated as well [18:41:59] as for actual things in the OS/installer... [18:42:05] "The installer started to perform its magic and I was presented with a little slide show made up of self-congratulatory marketing slogans:" [18:42:25] That's certainly true, maybe it's time to replace that little slide show with something more useful [18:42:39] we don't need to convince people who are installing it of reasons why they should give it a try [18:42:57] maybe make that slideshow about a few tips that will help the user get started [18:43:37] Stuff like "Did you know about Alt+F2? It allows you to start applications a lot faster than having to navigate through menus" [18:44:20] Generally stuff that we all rely on heavily, but that previous Windoze/Crapple/Gnome users have no idea about [18:44:29] any thoughts on that? [18:44:55] good idea [18:45:06] Possibly also "Did you know you don't have to just sit there watching the installer complete its work? Just launch a game from the menu, it doesn't affect installation" [18:45:19] or OMV comes with few extra repository like unsupported and non-free were you find xyz app and abc. To enable it use om-repo-pikcer [18:46:02] right [18:46:10] we do need to publicize more how we handle repositories [18:46:54] or even point out why non-free is a separate repository and why people do NOT want to install stupid nazividia drivers even if they've read somewhere that they should [18:47:25] also we can put on desktop in live mode and installed version too somethings like release note or errata or how-to-use-om-for-noobs-users [18:47:50] simple pdf file where we can explain few things [18:48:17] "Plasma on Wayland, which is an available session on the login screen, isn't quite in its prime yet. It mostly worked but there were various minor nibbles. The task switcher, for instance, didn't work. Using Alt-Tab would show me open windows, but I couldn't cycle through them." -- as long as this is true, maybe we shouldn't provide the option in sddm in a default install [18:48:50] AngryPenguin: agreed, pdf file or just a directory with html files etc. [18:50:03] Last point from that review that may need some consideration: "My main issue, though, was that I found the OpenMandriva-specific features rather underwhelming." [18:50:21] Do we need any new OM-specific features, or do we just need to make people more aware of the ones we have? [18:51:35] well, looks like we need resurrect drakxtool xD [18:51:43] We would probably have to use gtk to do this but: [18:52:35] if we could integrate all our OM features in one application like the old drakconf that would be helpful and make it much easier to make people aware of since they would all be in same application [18:52:46] surely we can do that with qt5? [18:53:19] sure [18:53:20] but maybe a lot of work [18:53:28] it's much easier with qt than with any grap [18:53:36] don't know if I could help but if I can I'm willing [18:53:59] bero ben79 If I good remember tpg found something that could replace the whole [18:54:10] It can't [18:54:22] http://cockpit-project.org/ [18:54:33] that thing is certainly useful, but doesn't cover stuff like desktop settings etc. [18:54:40] ahh ok [18:54:54] IMO it's more useful for servers [18:55:03] but can also be interesting for some aspects of a desktop system [18:55:19] but it can't replace anything that touches desktop settings etc. [18:56:08] If we could do something like this unique to ourselves it could create some distinction for the distro from certain others [18:58:15] we can import control center from ubuntu xD [18:58:37] we have omcc [18:58:41] +100 to good reviews :D [18:58:42] of course it can and should be extended [18:59:18] bero btw. have you looked at mozjs68? [18:59:36] AngryPenguin: yes, rebased all the patches but it still freaks out at compile time [19:00:07] unfortunately mozilla crackpots write horrible code :/ [19:00:32] this is blocker for gjs --> gnome-shell, gnome-panel and gnome-aplets [19:01:09] not having that broken crap is a feature ;) [19:02:47] Another way to do what I'm talking about is the ROSA approach of integrating all the tools in SystemSettings [19:03:40] which kind of makes sense if it is doable [19:04:02] The only problem with that is that it makes desktops other than plasma weird [19:04:14] good point [19:04:20] and very valid [19:04:25] you go to systemsettings to configure the system, but then you use it to configure the desktop background and it "doesn't work" because you just reconfigured plasma while you're using lxqt [19:04:38] I'll be right back... [19:06:14] bero I would like to update these packages before cp cooker if possible [19:06:37] AngryPenguin: sure, let's see if we can fix it all [19:06:37] looks like without new gjs is not possible [19:06:51] unfortunately we're talking about HORRIBLE code that may take long to fix [19:06:51] and new gjs require mozjs68 [19:07:13] bero mageia update mozjs to 68 [19:07:31] yes, they use old compilers [19:07:40] :( [19:07:46] so far the errors I've seen are because they do just about everything wrong that old compilers allowed them to do wrong [19:07:55] but making some progress... [19:08:44] bero: never looked at kaos croeso? [19:09:53] never seen it... do you have a link? [19:10:04] should be this https://github.com/KaOSx/croeso [19:14:53] that thing looks pretty good... [19:16:03] I wouldn't mind replacing om-welcome with something based on it [19:16:24] but of course that would make the "it doesn't have anything of its own" thing reviewers are complaining about even worse [19:16:39] yes [19:17:10] whatever one does, he's always wrong :) [19:19:04] the point is: what we care of and what we won't [19:40:08] OK, have we agreed to any course of action for the negative reviews? [19:41:51] yes, we should buy weapons and ammo [19:42:10] and use it against negative reviewers [19:42:12] xD [19:43:09] I think we pretty much agree, but we need people to actually do it ;) [19:43:22] rugyada: are you ok with creating some new slides for the installer? [19:44:00] I'd do it, but I simply can't make things look good [20:00:58] bero: sure [20:01:21] AngryPenguin: mozjs68 fixed [20:01:37] bero: I just need some inputs on what to write there [20:04:10] bero ohh good. Thanks [20:04:34] rugyada: see channel log for some examples... Essentially just useful things that may help the user figure out how to use his new system the right way... [20:05:11] ok [20:05:43] it's for what release? 4.2 I guess [20:05:49] OT: Why do we use grub2-editor instead of grub-customizer? Is this an upstream change? [20:06:46] grub-customizer is essentially dead, last release in 2013 [20:08:00] actually that was just the last announcement, there was another unannounced release in 2018 [20:08:49] I update it to latest version because someone on bugzilla reporiting issues with insgalling [20:10:01] somebody was blackcrack with his usual polite comments [20:18:01] om-cc and welcome great again [20:35:59] grub-customizer installs now but does not seem to work. [20:39:36] For making things better for users and reviewers we do need to upgrade our documentation. [20:40:23] Hello, are some people facing issues with some certificates? [20:40:55] But here: https://openmandriva.net/wiki/en/index.php?title=Welcome >>> I'm not sure how to start a new page. [20:41:35] Also I'm not sure what happened to our original wiki or if it will return? [20:42:44] I do think the documentation should go in our wiki. [20:43:44] Maybe we need web pages and a videos on "Hot to install " and "Getting started" ? [20:44:07] yes, would definitely be nice to improve documentation... [20:44:26] Hot to install sounds like a Freudian slip er, uh, How to install [20:44:41] ashledombos[m]: apparently -- one thing reviewers are screaming about is that nothing works because all our certificates are expired, even if I'm not seeing it [20:45:29] The situation with our web sites is going to get noticed and commented on by reviewers, that is inevitable [20:45:42] I don't understand the issues about certificates, unless it's related to package repos or something? [20:46:04] ben79 run customizer with root [20:46:15] Works for me [20:47:10] And I would contend that access to wiki, docs, and forum is part of the experience of installing and using a distro. [20:47:33] Zlypingwin[m]: error while loading the grub list [20:47:36] here [20:48:10] in VBox but it seems it should work in VBox [20:50:26] If I try to open grub-customizer form App menu>System it does nothing, and it should open a window asking for root passwd [20:50:58] Um, or I *think* it should [20:51:25] because it is in /sbin [20:51:37] /usr/sbin [20:52:27] anyway on websites all certificates are ok [20:52:37] so i guess it's something else [20:54:48] grub-customizer works in cooker maybe it does not work in VBox? [20:57:56] There are plenty of bugs for AIB. To many in fact. [20:59:55] ashledombos[m]: package repos are ok, complaints are specifically about the website [21:00:57] bero: any website in particular? [21:01:23] ashledombos[m]: "Unfortunately, the SSL certificate for wiki.openmandriva.org had expired in late December. As they have set up a redirect to always use HTTPS the page could only be accessed by adding an SSL exception in my browser, which I tend not to do. [21:01:23] [21:01:24] I wanted to report the expired certificate as a bug. It had been six weeks since the certificate had expired, and nobody seemed to have noticed the issue. The bug tracker, though, was also buggy. After entering my e-mail address I was supposed to be sent an account verification e-mail, but instead I got a blank page. [21:01:24] [21:01:24] The wiki got a new Let's Encrypt certificate on the 8th of February. However, to my surprise the wiki was complete empty. The domain showed a "MediaWiki has been installed" message, and there was no content whatsoever. And on that same day I noticed that the SSL certificate for the "downloads" subdomain had expired on the 8th February. [21:01:27] " [21:02:28] mmh downloads is not hosted by us [21:09:53] Is there something wrong with abf-downloads it seems impossibly slow [21:16:21] updating systems in VBox abf-downloads seems normal here [21:18:54] Some sort of local network problem then [21:18:58] OMG. OM-Welcome looks welcoming again and OM-C-C looks like a Control-Center again! [21:19:09] WTF [21:22:23] itchka: abf has been having network issues for a couple of weeks, but always recovers [21:22:23] ben79: Has the meeting died a death? [21:22:46] bero: OK I'm on a 4G router here so you can never be sure what is going on. [21:27:32] Anyway I had a long conversation with our bugzilla today and it told me that it was feeling ignored. [21:34:13] I guess I'd better take a look any biggies we might be able to close once the cp2rolling is done [21:35:43] To be honest I don't think any bugs I see are exactly biggies [21:36:12] This one has been around for ever: Kdenlive always segfaults on exit/close [21:36:15] https://issues.openmandriva.org/show_bug.cgi?id=2589 [21:37:28] I don't think I am able to fix that one..I can update the package and see what happens [21:37:59] There are 3 bugs I found filed against Lx 4.0 that I'm unsure how to handle, is it appropriate to just tell user to upgrade to 4.1? [21:38:45] https://issues.openmandriva.org/show_bug.cgi?id=2587 and https://issues.openmandriva.org/show_bug.cgi?id=2588 and https://issues.openmandriva.org/show_bug.cgi?id=2595 [21:38:52] IMO yes -- 4.0 is obsolete, users should just distro-sync [21:39:01] I think so too [21:39:25] good that is what I've been suggesting so far [21:41:08] oooh chwido informs us about bugzilla changes [21:41:13] So I can RESOLVED/CANTFIX them and ask user to refile bug report if issue persists in 4.1 but for all of those I'm fairly sure they won't be in 4.1 [21:42:04] ashledombos[m] I've changed multiple bugs today and seen nothing reported here [21:43:07] not sure exactly how it works [22:13:18] bero: itchka: Shouldn't we close OM Lx 4.0 for new bugs then? [22:13:31] I think yes. [22:13:55] Yes [22:14:31] OK, [22:17:01] OM Lx 4.0 is now no longer open for new bugs. [22:23:33] it's the end of an era [22:25:17] ah, it reminds me about 4.0 EOL statement [22:26:33] which should have been a TC meeting item too actually [22:26:53] just I forgot.. [22:28:40] bero: Has the slow running on the predator helios 500 been sorted out in the kernel now? [22:29:43] Uh, if we aren't accepting bug reports for 4.0 we should do an EOL statement [22:31:32] yes it's what I'm saying :) [22:32:21] if we do it right now can be documented and shared [22:44:31] sorry I am distracted by news reports in US. Apparently there is some virus going around [22:45:10] It's very serious ben79 [22:47:24] Oh it is very serious here, made worse by, well, lets not get in to why that would be [22:48:18] We have severly curtailed our social contact [22:48:44] I have as well [22:49:32] It's weird watching govt. folks trying to talk about this with our offending our Great and Supreme Leader [22:50:07] bizarre even [22:52:07] I don't wish to be rude about your president but even the republicans must be thinking now that it's time for him to go. [22:52:40] here we'll have everything closed: shops offices and everything except food shops, pharmacies and banks [22:53:20] We are just starting that here, but US seems to have been behind other countries in responding [22:53:40] Very sensible ruru it's the only way. [22:53:51] yes [22:54:10] The school my brother works at last week had a group return from Italy and they were put in a "sort of" quarentine for 14 days. [22:54:42] better safe (so to say) than sorrow [22:55:17] schools are already all closed since the end of Feb [22:55:58] The next month is going to be really telling; the only good news is that the Chinese seem to have got it under control and the infection rate is stabilising. [22:56:06] Well yeah, it is better to be safe, and this is not the flu the fatality rate is a least 10 time higher than the flu. [22:56:54] we are all exhorted to stay at home [22:57:42] Right this minute I'm listening to the Louisiana governor explain how we are dealing with testing when we simply don't have enough test available to meet CDC guidelines [22:57:45] ruru[m]: That's good asvice [22:58:22] 3 days ago the US President was telling people not to worry about it [22:58:24] ben79: Do you live in the sticks? [22:59:25] There aren't enough testes anywhere in US as far as I know. [22:59:39] enough tests damn it [23:00:00] :) But there's a load of collocks [23:00:03] oh so your president is making big parties, kiss whoever and live happy? [23:00:08] From sea to shining sea [23:00:42] Not heard that one before [23:01:05] kind of, he was shaking hands with people a few days ago, and it has been documented that he has had contact with people exposed to corona virus and he still has not been tested. [23:01:40] It turns out having conman in charge or your country may not be ideal when you have a real crisis [23:02:07] And what is weird it that he is a well known germaphobe [23:03:12] Hi ego is in complete control now he believes he's invincable [23:03:23] apparently [23:04:20] How on earth can the US not have these test kits when all these other countries do? And finally today people that matter are starting to ask WTF? [23:04:22] someone should endmeeting [23:04:30] Meeting ended by ben79. Total meeting length: 374 minutes