16:01:16 <itchka> #startmeeting
16:01:16 <chwido> Woof! Let's start the meeting. It's Wed Apr 27 16:01:16 2016 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:01:16 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:16 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:01:16 <chwido> Have a good meeting, don't bark too much!
16:03:16 <itchka> Who's here avokhmin bero fedya gbriglia HisShadow_ itchka joel_tess klebedeff linukiss n3npq markelite nicco OnlyHuman plfiorini satellit Son_Goku
16:03:26 <fedya> im
16:03:33 <itchka> Hope I haven't missed anyone
16:03:34 * bero is here, and Chwido and Laska are staring at the computer with me
16:03:42 * Son_Goku is here-ish
16:03:47 * n3npq puts the kettle on
16:03:54 <Son_Goku> I’m heading to work, so I should be back in ~15 minutes as Pharaoh_Atem
16:04:07 <itchka> agenda is here: https://project.openmandriva.org/meetings/60
16:04:39 <itchka> Just a few notes before we start.
16:05:31 <christann> I am here.
16:06:06 <itchka> The agenda is very large and I doubt if we will get through it all without some of us losing the will to live!! I suggest we set a time limit at which point we will call it a day and carry forward the other items.
16:06:33 <itchka> I suggest 2.5 hours as a reasonable limit.
16:07:11 <n3npq> where is the agenda?
16:07:22 <n3npq> ah sorry got it
16:08:52 <itchka> Some items may be able to be sent to Loomio for continued discussion. For this who perhaps don't know about loomio a look here would get you up to speed. https://www.loomio.org/d/N8aq6wPr/oin
16:09:43 <itchka> so here we go at 17:09 by my clock.
16:09:49 <itchka> #item 1
16:10:02 <itchka> #topic Release Status
16:10:05 <OnlyHuman> chwido: make the tea please
16:10:38 <itchka> bero: Do you want to kick this off please.
16:10:53 <bero> sure...
16:11:15 <bero> So overall Cooker is running quite well, but some updates have been broken for a few days
16:11:29 <bero> this is because of the kde applications 16.04.0 update taking a lot longer than usual
16:11:57 <bero> because upstream has decided to split kdepim into some 50 packages -- the packages for all the new subpackages had to be created first
16:12:09 <bero> done with that, now the script is running again to build the rest
16:12:40 <itchka> 50? is this texlive all over again?
16:12:49 <bero> but some of the packages are in a pretty bad shape (download URL wrong etc.), so even now things aren't going as smooth as they should
16:13:01 <HisShadow_> what's kdepim
16:13:23 <bero> but it won't take much longer, all the real problems are solved
16:13:40 <bero> HisShadow_: KDE Personal Information Management suite, including stuff like kmail, korganizer, knode
16:13:44 <itchka> HisShadow_: It's the information manager suite for KDE
16:14:15 <bero> itchka: sort of -- they've split out a number of libraries so other stuff can use them more easily etc.
16:15:09 <bero> Hopefully tomorrow updates will work as expected again
16:15:29 <itchka> bero: Lets hope it brings some improvements to kmail2 which is still pretty hopeless with it's filters.
16:15:32 <bero> In better news, k3b is back (people asked for that when it went missing)
16:16:20 <bero> once this is done and all packages are built, I'll try to build a new iso
16:16:35 <bero> that one should be pretty close to being ready for the next beta
16:17:39 <bero> On the 2.x side, tried to build an iso last week and it didn't boot, but I'd rather spend my time getting 3 in shape than trying to figure out what's up with 2.x, so if anyone else wants to look at that, that would be good...
16:17:50 <bero> that's pretty much all I had on release status
16:17:51 <itchka> bero: I've done some work on omdv-build-iso so that it can use overlayfs rather than aufs. I have it working but I would like someone to review my changes before final commit.
16:18:17 <bero> itchka: that sounds interesting, please put the changes somewhere so I can look
16:18:24 <itchka> bero: I can build working isos here.
16:18:37 <itchka> Will do
16:18:45 <bero> itchka: in abf?
16:19:16 <itchka> no the script can build locally as well so I build on muy box here.
16:20:03 <bero> then maybe abf is just calling it with the wrong parameters... Let's hope so
16:20:15 <itchka> The reason it's broken is probably because there is no aufs in the 4.5 kernel.
16:20:46 <itchka> That's why I fixed it up to work with overlayfs
16:20:48 <bero> true... One more reason to get overlayfs in
16:21:40 <itchka> I'll update my personal brach and youi can look at that.
16:22:42 <itchka> #item 1b
16:23:02 <itchka> #topic Branching cooker to Lx3
16:23:35 <bero> Related to the previous point -- we shouldn't be branching while in the middle of this
16:23:54 <bero> should do it as soon as the kde applications update is finished and things are working again
16:24:12 <bero> doing it before that would just mean having to build hundreds of packages twice
16:24:52 <bero> fedya: HisShadow_: Is everything on the abf side ready for branching? (Has anyone tested branching before?)
16:25:01 <HisShadow_> Just tell me when, and then me and my team of qualified chinese living in the basement will start adding lx3 branch to all repos manually
16:25:24 <itchka> HisShadow_: Like it :)))
16:25:59 <itchka> bero: Can you instigate this as soon as the kdepim update is ok?
16:26:15 <HisShadow_> no we haven't tested branching
16:26:30 <bero> itchka: sure
16:26:46 <bero> do we need to back up anything before testing branching?
16:26:47 <HisShadow_> shouldn't be too hard to do though
16:26:54 <HisShadow_> testing it I mean
16:27:27 <itchka> HisShadow_:  Is there anything reeally nasty that can happen?? Do we need some form of backup first?
16:28:43 <bero> A nasty thing like rm -rf $MISSPELLED_VARIABLE/ can be anywhere... So while it's unlikely, it's probably better to be on the safe side
16:29:08 <HisShadow_> I doubt it, the only thing that touches FS there is cp from old repo to the new one
16:29:21 <HisShadow_> but yeah, a back up wouldn't hurt
16:29:38 <HisShadow_> don't we have mirrors though?
16:29:53 <itchka> True
16:30:25 <bero> yes, we can assume they're doing the backups for us
16:30:25 <itchka> If need be I have 4Tb free here.
16:31:59 <itchka> Ok so it looks like we are good to go when bero gives the thumbs-up.
16:34:33 <itchka> #share Cooker is not updating properly due to huge (50 package) change to kdepim the major work is done and things should return to normal in a day or so. Once this is complete lx3 will be branched.
16:34:36 <bero> do we have anything other than the finished KDE Applications 16.04.0 update that people think absolutely should get in before branching?
16:34:58 <itchka> bero: Is clang ok in i586 now?
16:35:31 <bero> no, didn't have the time to look at i586. But it's probably no big deal given it builds KDE and all successfully
16:36:30 <rugyada> hi
16:36:37 <itchka> bero: It may not be building systemd properly I cannot seem to find anything else that is causing it not to boot.
16:36:44 <rugyada> bero: user avatars?
16:37:04 <bero> rugyada: right, will put those in place right after I'm done with the KApps update
16:37:10 <rugyada> ok
16:37:18 <rugyada> TY
16:37:47 <rugyada> and the OM icon as well
16:38:19 <bero> do I have that one? I think so, but not 100% sure
16:38:42 <rugyada> yes, the same email of avatars
16:40:11 <rugyada> and if possible the white on black scheme console :)
16:40:28 <HisShadow_> gonna go create a test platform and try to clone it
16:42:29 <bero> rugyada: are you sure about white on black as opposed to current gray on black? I think the gray on black variant is easier on the eyes (still very readable but not so much contrast that the bright spots make the eyes hurt)...
16:43:01 <rugyada> currently it's green on black
16:43:49 <bero> I'll check again on a new install, maybe it's gray on black here because settings didn't get updated at some point
16:43:51 <rugyada> btw grey on black is bit hard to read imho
16:45:09 <bero> it's what we've always had and it's what the text console looks like too...
16:45:38 <Pharaoh_Atem> back
16:46:04 <rugyada> preference 1= white on black, 2= grey on black
16:46:34 <bero> does anyone else have a preference there?
16:46:47 <bero> I think whatever works best for most of us...
16:47:04 <rugyada> I guess ben79 prefers white, but better to ask him directly
16:47:09 <klebedeff> rugyada has priority vote:))
16:47:27 <rugyada> klebedeff: :)
16:47:43 <christann> I prefer grey but will go along with white.
16:47:52 <itchka> Well I always switch to a light boackground with dark text I find the black background does not suit older eyes.
16:48:53 <itchka> Dark pastels is a nice compromise though
16:48:53 <rugyada> for older eyes maybe better more contrast (white on black) but may be just my feeling
16:49:43 <christann> It is easy enough to switch.
16:49:51 <itchka> Yes it is
16:51:10 <itchka> Also the default font size is quite small at 10 point I switch to 11 point and still everything fits ok.
16:55:34 <rugyada> I'd not make matter of life or death anyway, we're going to decide the default option, which should be better if some common setting (= no colors)
16:55:41 <rugyada> as long as no colors, white on black or grey on black works for me
16:56:01 <rugyada> still preference on white :)
16:56:30 <itchka> 1 for me
16:57:22 <itchka> It doesn't need to be set in stone now does it?
16:57:37 <rugyada> sure not :)
16:57:38 <OnlyHuman> 12 or 14 would be better :)
16:58:29 <itchka> Let's move on then to the next item.
16:58:43 <itchka> #item 2
16:59:03 <HisShadow_> wait, what about yellow text on red background
16:59:06 <itchka> #topic QA procedures
16:59:48 <rugyada> HisShadow_: why not. artwork team would be very happy -.-
16:59:50 <rugyada> :)))
17:01:33 <bero> ok, will switch to yellow on red then
17:01:34 <bero> ;)
17:01:59 <rugyada> ugh....
17:02:06 <rugyada> bero lol
17:02:17 <HisShadow_> wait, I got a better option. BLUE on red
17:03:50 <rugyada> has topic 1a been discussed already?
17:04:11 <klebedeff> yep, thank you rugyada
17:04:27 <klebedeff> not that we need to discuss somethimg there, but it needs to be recorded
17:04:49 <klebedeff> Luca had serious concerns and we need to announce the reminder
17:05:07 <klebedeff> 1a. Information: kind reminder of importance of following the rules for all. In particular: "Not to publish untested updates direct to the repos under any conditions or reasons". Thank you, this is important. What works for you - may break for all others.
17:05:16 <klebedeff> thanks to all:)
17:05:27 <klebedeff> itchka I am off the floor:)
17:06:57 <itchka> Thank you Kate
17:07:58 <HisShadow_> we had wrong option for contrib in oma2014 and updates were published automatically there
17:08:31 <itchka> I think what is needed to sort this is to be abl;e to set the default publishing status of 2014.2 to testing. As I understand it this cannot be done yet in ABF and people forget to set  publish to testing when they do builds.
17:09:08 <itchka> HisShadow_: Is it fixed now?
17:09:21 <HisShadow_> yes
17:09:30 <itchka> ie 2014 defaults to publish to testing?
17:09:48 <HisShadow_> no, it defaults to no publish atm, shouldn't be too hard to change it though
17:09:55 <HisShadow_> right now you need to press the button
17:10:41 <OnlyHuman> do people want distro as old as 2014?
17:11:02 <HisShadow_> um, that's the only thing before cooker
17:11:08 <klebedeff> OnlyHuman off topic!!!:)
17:11:10 <itchka> Ok I guess that's safe enough so do the built rpms end up in testing?
17:12:05 <HisShadow_> itchka: there are 2 buttons, publish and publish into testing
17:14:36 <itchka> HisShadow_: Ok well the way we worked it before in released distros was that the default publishing status was to testing. Once the package had at least 3 good votes we would release it to the main repo
17:15:18 <bero> that's probably where we should go again
17:15:33 <itchka> Unfortunatel the application we were using for the voting was not compatible with the current abf so we have to do that by hand at the moment.
17:16:06 <itchka> bero: Yes I think that tyhat should be the default at this point in time.
17:16:40 <itchka> We need to look at fixing kahinah
17:17:10 <HisShadow_> I don't know why it's not compatible, gotta talk to the creator of kahinah
17:18:25 <itchka> It's Robert Xu I'll give you his email.
17:19:10 <HisShadow_> well he is right here in this channel
17:19:26 <HisShadow_> I have tried to raise him here, but no success
17:19:41 <itchka> Robert Xu <robxu9@gmail.com>
17:20:14 <itchka> I think he has just got his first job and is pretty busy.
17:20:50 <itchka> It would almost make sens for kahinah to be an integral part of abf
17:22:12 <HisShadow_> well I'm sure I can fix it myself If I had access to the code
17:22:17 <itchka> You can look at the code here https://github.com/robxu9/kahinah
17:22:37 <itchka> It's written in Go
17:23:08 <itchka> apparently
17:23:29 <HisShadow_> no I mean the actual one deployed at jasper.oma
17:23:34 <HisShadow_> to mess around
17:24:52 <itchka> HisShadow_: Ok I can sort out access for you on that later.
17:25:58 <itchka> I'll put it on my TODO list
17:27:03 <itchka> Lets's move on to 2
17:27:28 <itchka> QA Procedures
17:28:02 <itchka> Background
17:29:50 <itchka> In the past a procedure was instigated where before an iso was put on general release outside of the Cooker/QA community it was first passed to the QA team for assessment.
17:30:41 <itchka> The reason for this was that previously iso's were being released whose names seemed to indicate that they were some sort of finished product.
17:31:37 <itchka> Some of them had serious defects that caused them to malfunction in such a way that they caused disappointment to the user community.
17:31:38 <n3npq> are you seriously suggesting that the existing "pass iso to QA before release" needs changing? or is the issue misnaming?
17:32:28 <itchka> n3npq: I am giving the background to why this item is on the agenda. I'm not suggestiung anything at this point.
17:32:59 <n3npq> good. ok, so the procedures aren't being followed leading to bad PR.
17:37:14 <itchka> Recently there was a BETA1 iso that was submitted which had a defect which on balance was considered serious enough to reject it. It was a difficult decision which involved the radeon driver presnting a black screen on R600 systems (as well as others but these were in more complex circumstances)
17:38:16 <itchka> There were issues with some other graphics drivers too but these were less severe.
17:39:17 <itchka> The decision demotivated to developer to the point where he temporarily (fortunately) with drew his support.
17:40:01 <ashledombos> hi
17:41:43 <klebedeff> hi ashledombos
17:42:52 <ashledombos> I see the discussion is about QA procedures
17:43:11 <klebedeff> If I may - a number of situations showed that there is no full clarity in teams about certain QA aspects. And this is very important to clarify these
17:43:16 <bero> I think the takeaway needs to be that we need more communication between development and QA
17:43:22 <bero> There's a problem with misnamed ISOs probably
17:43:51 <bero> there's also a problem with (sometimes) QA trying to achieve a standard that is much higher than e.g. Fedora's or Ubuntu's while we have less than 0.1% their manpower
17:43:53 <itchka> The purpose of this agenda item is to discuss the level of QA applied tro our releases to determine whether it is appropriate for the manpower resources that we have available to us and to explore ways where developers and QA can work to toward a commmonly acceptable and achievable level of quality.
17:44:01 <bero> when there's a conflict, we need to sort it out...
17:44:38 <klebedeff> clarity needs to be achieved on listed points. In the ground of any 'conflict' there is a different understanding of definitions
17:44:52 <ashledombos> sorry i pop out but bero what do you have in mind?
17:44:57 <klebedeff> so apparently that needs to be fixed
17:45:04 <ashledombos> «here's also a problem with (sometimes) QA trying to achieve a standard that is much higher than e.g. Fedora's or Ubuntu's »
17:45:04 <itchka> This will inevitably involve compromise and I would request that we keep the discussion to factual level so that we can address the issues in a contructive way.
17:45:46 <itchka> constructive
17:46:41 <klebedeff> #bug definition
17:46:42 <bero> ashledombos: We've had situations earlier where some people decided to vote no-go an ISO because of a "pet peeve" that really shouldn't have been a blocker -- so when there's a no-go that developers don't agree with, we need to talk about it...
17:48:05 <christann> What should our ISO release standard be?
17:48:26 <itchka> We have several bullet points in the agenda for this subject ineveitably these types of discussion can range widely so I would ask that everyone stick to the subject in hand unless there is an absolute necessity to deaprt from it.
17:48:36 <christann> What sort of bugs can we allow in a Beta ISO?
17:48:40 <itchka> #item 2a
17:48:53 <itchka> #topic Bug Definintion.
17:49:43 <rugyada> another issue is that QA/testers need more time for testing when it's involved GO-NOGO decision/advice
17:49:49 <itchka> christann: Please can we deal with the agenda items first as we have limited time.
17:50:17 <christann> itchka: OK
17:51:31 <ashledombos> Do the subject means «level of bugs» definintion?
17:51:38 <itchka> So lets look at Bug Definition I'm going to adress this question to the two most experienced open sourcers that I know her bero and n3npq I hope I haven't offended anyone else it's not my intention
17:52:26 <itchka> Guys please lets have a definition of a bug in general terms
17:54:18 <bero> Well, technically a bug is anything that can go wrong -- but in terms of what should be treated as an important bug, it has to be at least reliably reproducable
17:54:50 <n3npq> itchka: include also a definition of "feature" and "acceptance" testing please. Most linux devels/users are confused by the fact that bugzilla is used for tracking not only bugs, but also "features" and "procedures". Hence "bug" definitions are tainted with RFE's and procedural transparency.
17:55:07 <bero> There's nothing more frustrating than getting something along the lines of "NO-GO because xyz doesn't work" when xyz does work to anyone trying to reproduce it
17:57:13 <itchka> Ok bero I think n3npq would agre with your first statement. Perhaps we need to examine this statement about reproducibility since it seems key to me.
17:57:55 <itchka> n3npq: I would like to clarify your statement after we have dealt with this point
17:58:19 <n3npq> for distribution iso work (and also messy upgrades like "new compiler" or "new KDE"), I'd suggest that the existing ABF -> mirrors -> users is woefully deficient procedure. Insert an acceptance test into the ABF -> mirrors -> users somehow with transparent criteria defining "acceptance".
17:59:01 <bero> n3npq: agreed, that's pretty much what we're trying to do with the semi-rolling release model we're thinking of adopting after the 3.0 release
17:59:53 <itchka> bero: Ok we have a definition that says that a bug must be something that is reproducable. The real question here then is reproducable by whom?
18:00:13 <n3npq> by "transparent" I'd suggest listing the display hardware that has been tested. the expectation that "BETA1" == "works on Radeon R600" seems to be the issue that triggered this discussion.
18:01:30 <itchka> If a developer cannot reproduce a bug does this make it now not a bug. How do we define reproducable in these circustances..
18:02:07 <itchka> This is particularly important where harware is involved.
18:02:22 <itchka> s/harware/hardware
18:02:25 <bero> While this is hardly the most professional stance to take, the realistic one to take is "someone with the skills to fix it must have a way to reproduce it"
18:02:50 <bero> And I think that's pretty much what the other distributions are doing as well, you'll always find some hardware on which a particular distribution doesn't work
18:03:07 <bero> of course we should try to keep the number of pieces of hardware where it doesn't work as close to 0 as possible
18:03:11 <n3npq> bero: all this pseudo, semi-rolling, alpha/beta/gamma, bug vs feature, tested or broken, is confusing. branch the release early to protect both "rolling" and "BETA" labeling and QA testing procedures imho.
18:04:10 <bero> but it will never be 0, nobody gets it to 0. Not Ubuntu, not Microsoft, not us (Apple goes as far as saying "we'll only support one particular computer" because they're so scared of all the hardware support/driver issues...)
18:04:30 <itchka> n3npq: Please lets stick to the item we are discussing because this is crucial to the health of the relationship between Developers and QA.
18:04:53 <n3npq> the downside of early branching is that you will have a huge "zero-day upgrade" … that's life imho.
18:05:15 <bero> n3npq: agreed in general -- that's part of the new release plan as well.
18:05:29 <n3npq> itchka: I am trying to stick to the issue … sorry if that isn't clear.
18:05:45 <itchka> bero: As I understand it our level of quality in that department is pretty good.
18:08:11 <bero> itchka: We don't really know how well we're doing there simply because we don't have testing on 5000 different pieces of hardware - but we're trying to be good and at least in hardware I have access to, we're generally doing well
18:08:22 <itchka> n3npq: Yes I do see where you are coming from but lets try and arrive at a conclusion in a step by step fashion so that everyone can benefit from the insights gained.
18:08:28 <bero> you may get a totally different response from someone who has a collection of old hardware that still has ISA slots or the likes
18:09:09 <HisShadow_> ISA slots -_-
18:10:36 <itchka> Most of the QA disaster area lies in the graphics adapter side of things  because these are items that directly affect how the user feels about the distribution.
18:11:04 <christann> and are the hardest to test due to the number of possible combinations.
18:11:33 <bero> exactly
18:12:00 <bero> and even because 2 graphics cards with the exact same GPU on them don't necessarily behave the same
18:12:25 <itchka> We need to find a way to sort this part out either by defining what we are going to support at the outset or by starting development and testing of graphical servers before other parts of the software stack if indeed that is practical.
18:12:50 <bero> I think we need to be realistic there
18:13:00 <bero> we don't have any real expert on graphics drivers on the team
18:13:37 <bero> generally all we can do (unless we have a LOT of time on our hands, and GOOD debug info, like the problem happening on an actual developer's machine) is say we support whatever is supported by upstream drivers
18:13:54 <n3npq> itchka: running a list of the hardware actually tested on avoids the harder decision: is that list sufficient for an ISO to be called "BETA"?
18:13:57 <bero> and sometimes when we're made aware of a problem we can check if a newer (possibly unreleased) upstream driver already fixes it
18:14:22 <bero> but beyond that there's just little we can do
18:14:40 <bero> unless you count "delay the release indefinitely until upstream projects provide a fix"
18:14:57 <bero> which I would see as the right answer only if it's really a problem affecting a lot of potential users
18:15:11 <n3npq> a list enhances transparency, and provides a means to track (by adding a specific wonky driver) to the QA check-list
18:16:20 <n3npq> a list also accomodates de facto available hardware: its really hard to debug a display driver when you haven't the hardware.
18:17:01 <itchka> Ok all good suggestions there's another I'd like to make and that is that we be conservative about the graphical server we choose at the "design" stage the more mature the version the less likely we are to experience trouble. It's true that we might lack some supports for later GPU's but if we keep the dkms and proprietry drivers in good nick then those with later chips have an option.
18:17:37 <bero> I'd say the exact opposite
18:17:56 <bero> we need to stay on top of the stack to have recent hardware support added and numerous bugs fixed
18:18:14 <n3npq> bero: its hard to see the opposite" … can you state precisely.
18:18:45 <n3npq> ah k … yes its harder to support legacy than bleeding edge hardwate
18:19:04 <bero> sure -- what I'm thinking is we need to move to new X servers, mesa versions etc. to make sure we can benefit from added support for new hardware as well as bugfixes for older hardware
18:19:22 <bero> upstream development has the same issues as us -- they fix one chip and break another
18:19:36 <bero> but they get a load of bug reports and typically have WAY more test hardware available
18:19:59 <bero> so a newer driver release etc. is far more likely to be a step forward than a step backward in terms of supported hardware
18:20:07 <n3npq> the need to continually retest "everything" for every change is another part of the puzzle
18:20:34 <bero> unless we're talking about nvidia binary drivers and friends that intentionally remove support for old hardware so people will have to buy their newest products
18:20:43 <bero> binary drivers should simply not be used when avoidable at all
18:24:20 <itchka> But this is like saying the the only people with any sort of guarantee to boot to a graphical screen are those with the latest hardware. It may be good for a minority with the hardware but how about average Joe user who maybe wants to try our offering.
18:26:05 <n3npq> itchka: write a script that verifies joe users hardware against QA's "tested" list. colorize the output with BOLD_RED if untested.
18:26:20 <bero> no, like I've said before, the upstream drivers try to add support for more (including old) hardware all the time
18:26:31 <bero> a new version is generally more likely to work than an older one
18:26:56 <bero> simply because the newer one includes the fixes from upstream developers for the reports they got
18:27:43 * n3npq knotes that ROSA's (actually ponomarenko iirc) hardware list is/was quite good when I last looked.
18:27:47 <n3npq> notes
18:28:54 <itchka> Ok bero if we accept that as a given then how do we QA the gaphical server interms of hardware. If I look at my xorg.0.log I see a list of supported cards listed by the driver. Do we use that list as a reference?
18:30:00 <bero> The problem is that we have no idea whether or not all of those cards actually work -- but it's probably as close as we can get to a reasonable list of what is expected to work
18:30:24 <bero> this has to be done for every driver of course, the xorg.0.log list is what cards should be supported by the particular driver you're using
18:30:49 <n3npq> itchka: upstream lists are often poorly maintained. add attributes like "tested by QA" "claimed working by upstream" to the list. also add "tested by another user" and crowd source a WORKSFORME refcount.
18:31:30 <itchka> n3npq: Yes that's a good idea.
18:31:48 <bero> yes, that sounds like a good idea
18:33:08 <itchka> Ok there's one more aspect to this and that is combinations of cards. If we could clear this one then I think we can call the meeting to a close for this session.
18:34:04 <n3npq> is there sufficient resources in OMA to attempt a hardware compatibility list? the usual knee jerk discussion is privacy, which can be handled with either "opt-in" (which nobody uses) or "opt-out" (which handles privacy freaks but can be surprising with info uploads after/during installs)
18:34:37 <bero> n3npq: I think it would be good to have, but I don't think we have the resources right now
18:34:52 <n3npq> ROSA's hw compatibility is/was the best I've ever seen … ymmv. and if no infrastructure, then my comments are OT.
18:35:03 <itchka> There is a common situation that occurs where a user fits a more powerful graphics card to their machine. I'm talking a pci/agp/pcie slot addition here not the stange arrangments you get in soime laptops.
18:36:54 <itchka> In 9 cases out of 10 this works fine but it seems that where the Intel driver is concerned there are sometimes issues.
18:37:00 <n3npq> possibly OT: I can extend RPM to warn when package is installed with untested hardware. SuSE has some RPM patches that could be swiped.
18:37:53 <bero> n3npq: That could definitely be useful in the longer run - but short term, probably it'll scare more users than it helps given how few users and testers we have. Essentially everything would get marked potentially unsupported
18:38:43 <itchka> Do we accept that people will do this (upgrade the graphics adapter to an off motherboard type) and support it?
18:38:45 <n3npq> bero: yes lusers are so frigging timid, scared by any unexpected warning.
18:40:03 <bero> itchka: I'd say this is again something where we have to be realistic in terms of what we can do, so my answer is "yes, but we can only support it to the extent it's supported by upstream drivers and work within that framework"
18:40:47 <bero> So again if we see a particular combination that fails, we can try to get it to work by a little tweaking, but if that doesn't do the job, our answer has to be "take it up with upstream driver developers, it'll be fixed in OMLx when they release a new driver fixing it"
18:41:42 <n3npq> bero: yes a black list works better than a white list
18:41:54 <itchka> But how do we tell whats supported and what is not? I could say that my experience is that this kind of upgrade has worked for me in all cases bar one and therefore I conclude that it is supported.
18:42:27 <itchka> I must have tested at leat ten combinations over time.
18:43:18 <n3npq> itchka: running the negative black list waning joe luser of currently known borkage is likelier to solve the problem better than anything else.
18:43:26 <n3npq> warning
18:44:15 <bero> itchka: much the same here, and we can't really tell what's supported because we have neither the resources nor an unlimited supply of test hardware -- so in general the answer has to be something along the lines of "it's supported in general, but we can't guarantee it will work. Give it a try, report if it works, and if it doesn't, we'll help you file a report with upstream developers"
18:46:00 <n3npq> managing a black list also changes the GO vs NO-GO decision on the entire release by changing the discussion to more specific "add to black list" and "move driver from black list". sure there are some MUSTHAVE drivers for final release, but that need not affect alpha/beta/gamma designations (with appropriate criteria)
18:46:28 <bero> right
18:48:48 <itchka> bero: I understand what you are saying but think about it. Here I am Joe user who wants to use OpenMandriva I slot in my usb stick and start the boot and Oh Dear black screen. I'm not going to be filing any bug reports am I. In these circs QA is the only way things can get better if they test and find a problem on what should reasonably be a supported combiination do we report a bug and consider it to have a level
18:48:50 <itchka> of seriousness perhaps to be negociated.
18:49:26 <HisShadow_> why not fall back to the cpu driver on iso so that user at least installs mandriva on the harddrive
18:50:00 <n3npq> itchka: stuff happens. it only gets out of hand when the borkage goes viral when joe user is a complainer.
18:50:27 <n3npq> manage the experience transparently
18:50:37 <n3npq> preempt the bad PR
18:51:34 <bero> itchka: I agree about that absolutely -- we should take a bug report, but essentially the only thing we can do is say "we'll take it up with upstream developers, at some point we'll get a new driver, then we can try again"
18:52:13 <bero> HisShadow_: we already do that - but of course if the "right" driver actually just renders garbage or turns the screen off or whatever instead of crashing, we have no way of automatically detecting we shouldn't use it
18:52:18 <bero> that's where we need the blacklist again
18:53:04 <HisShadow_> bero: err, I rather wnated to say to use it by default on the iso
18:53:06 <bero> itchka: The thing is, we'll ALWAYS end up with some users who don't even get to a booting system and there's nothing we can do about it short of testing every single computer in the world, or going the Apple way and saying "We support exactly this one computer, nothing more nothing less"
18:53:28 <bero> HisShadow_: Then people will come complaining "It installs, but the installed system doesn't boot", which is even worse...
18:54:04 <bero> It's "I tried it and it doesn't work" vs. "I tried, it didn't work, but erased my working old stuff!"
18:54:44 <HisShadow_> hm, yeah, true
18:55:27 <bero> and we do have "boot in safe mode" or something on the iso
18:55:31 <bero> so people can just try that
18:56:07 <itchka> bero: Yes I understand that there's an exponential law going on here. There is no expectaion to fix everything just the need to find an acceptable level of failure.
18:56:41 <bero> itchka: exactly
18:57:27 <itchka> Ok we have had our time and more on this and we have made some progress.
18:58:37 <itchka> What I will do now is I think is to summarise the discussion in an email to the cooker list for further discussion as to how we might implement our approach to graphics driver failure.
18:58:38 <bero> In the end we just have to be realistic, and accept that whatever fails with upstream drivers and is not related to the way we set them up or so is "their" problem (as in upstream driver developers')
18:59:17 <bero> we can help people file bug reports there, and we can help get their box in vesa mode or whatever, but unless the problem is really obvious we can't be expected to fix the drivers
19:01:25 <itchka> Is everyone happyu to pick this one up again on the ML or alternatively in Loomio I don't mind which.
19:04:06 <itchka> I have hungry people baying at my heels so I'm goung to have to close the meeting or hand over to another to continue.
19:04:55 <n3npq> yes but … the discussion is sisyphean, there will always be unhappy users/testers/devels. the stress comes when the computer is rendered useless, either by no bootie! or no display! or otherwise ...
19:05:04 <itchka> If no voluteers I'll close in 5 minutes
19:05:37 <itchka> n3npq: A boot option that submits a bug report detailing the hardware.
19:06:14 <itchka> With modern boxes it could be an EFI application
19:06:24 <n3npq> smoke signals are low bandwidth and increase carbon footprint and cause global warning
19:06:32 <itchka> :)
19:08:58 <n3npq> is anyone brave enuf to test rpm-5.4.16? now released … 1.1B fuzzy execs to detect all possible segfauls with tampered content
19:09:21 <itchka> wow!
19:09:42 * n3npq adds to his bucket list: fiorst time I have ever intentionally done anything 1 billion times
19:10:03 <itchka> #endmeeting