15:10:49 <itchka_> #startmeeting
15:10:49 <chwido> Woof! Let's start the meeting. It's Wed May  4 15:10:49 2016 UTC. The chair is itchka_. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:10:49 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:10:49 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:10:49 <chwido> Have a good meeting, don't bark too much!
15:10:53 <klebedeff> hi
15:10:56 <OnlyHuman> chwido: bark itchka_
15:10:56 * chwido barks at itchka_.
15:10:56 * HisShadow slaps chwido around a bit with a large trout
15:11:06 <klebedeff> avokhmin barscka bero blackcrack fedya_ fedya_ gbriglia HisShadow JLP n3npq oiram73 OnlyHuman Pharaoh_Atem plfiorini satellit Son_Goku teo- Xu_R
15:11:11 <klebedeff> :)))
15:11:24 <itchka_> The agenda is here:- https://project.openmandriva.org/meetings/61
15:11:25 * bero barks at chwido
15:11:34 <Son_Goku> hello
15:11:46 <OnlyHuman> :)
15:12:17 <Son_Goku> I’ve got to go to work, so I should be back in ~30 minutes or so
15:12:39 <itchka_> We will pick up where we left off with the QA stuff when the release report is done. Like last week the I would like to keep the meeting to 2.5 hours max.
15:12:54 <itchka_> I may end earlier though if we are at a convenient point.
15:13:05 <itchka_> #item 1
15:13:16 <itchka_> #topic Release report
15:13:23 <itchka_> Over to you bero
15:13:38 <itchka_> Though I have to odd thinng to add.
15:13:43 <bero> So from where I stand things are looking good and still getting better
15:14:14 <itchka_> bero: Are we ready to fork?
15:14:17 <bero> The KDE Applications 16.04 build is still in progress (everything sorted out, but some build machines take forever)
15:14:29 <bero> once that's done (maybe 1 more day), we're ready to fork
15:15:25 <itchka_> It would be good to set a deadline for this if possible..you know how things drift...
15:15:26 <bero> one last thing we may want to do before forking is updating poppler
15:15:41 <bero> but that will require a rebuild of anything that uses it
15:16:02 <bero> but it does fix a fairly important issue (crashes while activating PDF forms)
15:16:12 * blackcrack think by kde.. on Kmail and Kleoparta what need for task-plasma install
15:16:45 <bero> can't really set a deadline for the build boxes -- they won't work any faster because we give them a deadline ;)
15:16:52 <bero> and it's just waiting for them now
15:16:55 <itchka_> bero: That is an important issue any idea of the number of packages involved?
15:17:24 <itchka_> The poppler thing I mean
15:17:24 <HisShadow> bero: in the future when building for aarch64 and x86, set native build, so that qemu won't freeze in the middle of things
15:18:21 <bero> Not that many - but most of them are big: okular, qpdfview, calligra, cups, cups-filters, inkscape, libreoffice, scribus, texlive-luatex, texlive-pdftex, texlive-pdftools, texlive-xetex
15:18:52 <bero> HisShadow: is there a way to set native build when running "abf chain_build"? (That's what the update script does)
15:19:07 <bero> qemu timeouts are indeed what delayed the builds quite a bit
15:19:33 <itchka_> HisShadow: Perhaps we should make it the default for aarch64 and x86 we shouldn't be trying to build x86 code on quemu running on arch that's crazy.
15:20:03 <itchka_> aarch
15:20:08 <HisShadow> no, x86 isn't built in qemu, it's just googlebuilder is fast and it has x86 in native build
15:20:21 <HisShadow> bero: what's abf chain_build ?
15:21:07 <bero> HisShadow: useful feature of the abf command line client -- essentially takes a list of packages as input and builds them in the right order
15:21:57 <bero> HisShadow: https://github.com/OpenMandrivaSoftware/kde-packaging-tools/blob/master/kapps.buildlist is an example of a package list that can be run through abf chain_build -- anything that is on the same line will be built in parallel, anything on a new line waits for the other builds to be finsihed first
15:22:19 <HisShadow> bero: hold on, which one of the comand loine clinets? abb or abf-console-client?
15:22:40 <bero> HisShadow: abf-console-client
15:28:02 <HisShadow> bero: alright, I'll fix it
15:29:52 <bero> Other than that, the version number change and new graphics still have to be merged
15:30:11 <itchka_> bero: If we do poppler I would guess we are looking at a couple of days if all resources are up..
15:30:13 <bero> but then I think we're ready for the next beta release (if not rc)
15:30:52 <bero> We can omit the arm builds for now (and run those after the iso is done), then it won't take that long
15:31:40 <bero> or we can update it after the next beta, but I'd definitely like to have it in before the final
15:32:34 <itchka_> bero: Good idea. Ok then but please nothing else until after we have forked we must set a mark in the sand.
15:34:51 <bero> agreed
15:34:54 <itchka_> I hope we can get Calamares 2.3 before then too as it fixes some nasty traps in the partition manager but that's not going to take long compared to libreoffice etc.
15:35:27 <teo-> I can probably weigh in on that :)
15:35:52 <teo-> Cala 2.3 is coming in the next few weeks, but it will probably only have LUKS support for automated install modes as a start
15:36:01 <itchka_> That woulkd be great teo~ it would be good to release with that fixed.
15:36:12 <teo-> an alpha should be out soonish, maybe even this week
15:36:20 <teo-> itchka_: what's the specific issue you need a fix for?
15:37:36 <itchka_> teo~: It's the non-sticky settings in the partition manager they always revert when the page is refreshed. I filed a bug. It was going to be fixed in 2.2 but I think it must have been missed.
15:39:48 <teo-> ah, that one, right, it might not be fixed in master yet even
15:40:13 <teo-> itchka_: can you please write me the bug link in the Cala channel, I might have an idea
15:40:38 <itchka_> OK I'll look it up
15:42:30 <itchka_> teo~: Pasted
15:48:02 <itchka_> I have one thing for release report. I have fixed  omdv-build-iso so that it builds cooker. It will also have some enhancements to the local mode which will make it much quicker and easier to and quick tp build local isos. Should also help devs who want to do quick tests. These will be committed very soon now.
15:53:17 <bero> great!
15:56:12 <itchka_> Ok lets hope that next meeting may even see an RC
16:01:06 <itchka_> #share The release of a potential beta/rc is waiting for the completion of the kde16.04 apps packages; a rebuild of poppler and it's dependencies which will fix crashes when using form data. It is hoped that fixes for a Calamares installer issue will also be incorporated. When the two major items are complete the repo will be forked to OMLx3
16:01:17 <itchka_> #item 2
16:02:22 <itchka_> #topic QA Procedures. Location of the record of QA related decisions
16:03:19 <itchka_> It has been suggested that any output of QA related decisions could be on the QA wiki page.
16:03:28 <itchka_> Any comments?
16:05:37 <itchka_> Alternatives may be the QA discourse forum or the #share recording of the TC proceedings.
16:07:13 <itchka_> My preference is the QA forum area as this is visible to devs, QA and users alike. Any permanent decisions should obviously be recored in the wiki.
16:07:33 <itchka_> recored=recorded.
16:09:10 <itchka_> Are there any alternative proposals?
16:10:25 <itchka_> ben79: Hi
16:10:35 <ben79> Hello
16:10:46 <bero> itchka_: that works for me
16:11:51 <itchka_> Thanks bero I've just pasted it to ben79 for comment
16:14:50 <ben79> Yes, I'm OK with this.
16:15:02 <itchka_> Thanks Ben
16:16:20 <itchka_> #action All QA decisions to be posted to the discourse QA forum with permanent changes to procedures or structures to be posted to the QA Wiki.
16:18:22 <itchka_> #share A decision was taken to publish QA decisions in the QA section of the OM discourse forums. Permanent changes to procedures will be added to the QA Wiki
16:18:55 <itchka_> #topic QA Procedures b. Triage
16:20:27 <rugyada> PS> QA forum section is: https://forum.openmandriva.org/c/en/qa
16:21:48 <itchka_> So we need to have a discussion on triage. I think it would be helpful if we first had a definition. I beleive this term started in the medical arena.
16:21:51 <itchka_> noun
16:21:53 <itchka_> 1.
16:21:54 <itchka_> the process of sorting victims, as of a battle or disaster, to determine medical priority in order to increase the number of survivors.
16:21:56 <itchka_> 2.
16:21:57 <itchka_> the determination of priorities for action:
16:21:59 <itchka_> She began her workday with a triage of emails.
16:22:52 <itchka_> So how do we apply this to bugs?
16:23:19 <itchka_> The definition is a little broad..
16:24:00 <itchka_> Hmm that's a split infinitive if ever there was one!!:)
16:25:37 <itchka_> The trouble with any bug triaging is that the importance of bugs tend to differ between user and developer and this causes some trouble.
16:26:26 <itchka_> We have to someway define a triage procedure that takes into account different degrees of system knowledge.
16:27:45 <itchka_> We go back to the situation with graphics drivers to illustrate this conundrum.
16:27:48 <Pharaoh_Atem> back
16:28:36 <bero> got to take the dogs outside quickly, brb
16:29:01 <itchka_> Although we discussed and resolved this last week (at least to some extent) it does illustrate the problem.
16:29:05 <itchka_> ok
16:31:29 <itchka_> In previous circumstances a bug which seemed to exclude the use of a number of graphics adapters which were supposed to be supported by the current drivers were broken.
16:34:51 <itchka_> For the users (and therefore QA) this represents major breakage and should have priority over pretty much all other bugs in the OS apart from perhaps boot bugs. However the perception from the developer side is that we don't have the skills/resources to fix it so it literally has no importance until neww code is released upstream which may fix it.
16:37:52 <itchka_> To me this is a communication problem and it has arisen over a number of bug types (typically graphical) plymouth springs to mind.
16:39:28 <itchka_> In these situations I think we should interpret the word "triage" as being "Management of Expectation"
16:40:36 <itchka_> Would anyone else care to comment on this statement.
16:41:33 <bero> back
16:42:04 <itchka_> Hi
16:42:42 <bero> I agree with that -- we should of course look into any such bug, but if it's not getting an upstream fix and it's not caused by a misconfiguration, management of expectation is what we need to do about it
16:44:12 <itchka_> Ok bero thanks for that.
16:45:55 <itchka_> Ok so lets look at how we do "MoE"
16:47:13 <itchka_> I think some of this has to do with how a bug is presented..
16:48:16 <itchka_> Developers ahve a hard time of things they are always between a rock and a hard place when it comes to bugs especially when we are as shorthanded as we are.
16:49:34 <itchka_> Unfortunately though proper MoE relies on the developers interacting with the kind of bugs previously mentioned.
16:50:09 <itchka_> Which makes additional demands on them.
16:51:20 <itchka_> Users who demand that a bug be fixed are likely to get curt replies if any from a harried dev.
16:52:20 <itchka_> but there's no getting away from the fact that sometimes devs need to provide input.
16:54:52 <bero> true
16:57:28 <itchka_> Can QA play a part in MoE. I think we need to examine this.
16:58:09 <itchka_> The fixing or at least determination of the characteristics of a bug is to an extent formulaic.
16:59:10 <itchka_> This doesn't apply to every bug but it does apply to a sizable majority.
17:00:45 <itchka_> Developers can make fairly rapid diagnosis if they have access to all the information they can even do this though they may not be able to reproduce the bug themselves.
17:01:55 <bero> One thing that would be good for some of the most commonly reported bugs would be a feature in bugzilla to send out a canned reply without having to type it over and over again, essentially friendly versions of "upstream's problem, we'll fix it when they've released a new version that fixes it", "not reproducable here, we need better information before we can do anything about it", etc.
17:04:36 <itchka_> Yes I can certainly see the value of that with those sort of things though I think there is a need for a personal touch with maybe a greeting and a name at the end so the user feels they have not been dealt with by a robot.
17:05:09 <itchka_> But that is onl;y a few words not paragraphs
17:08:08 <itchka_> The formulaic approach to information gathering could be very helpful too. One area I myself have struggled with is gathering meaningful logs for the developer to work with.
17:10:08 <itchka_> When something goes wrong particularly with crashes users don't know how to get the information back..I know I don't sometimes. What is needed is a kind of tre chart that shows the steps a developer would take to isolate a problem.
17:11:48 <itchka_> With such information relatively inexpert users could gather meaningful information for the developer to work with. Even if the chart perhaps to complex for the ordinary user to wish to spend time on at least QA could improve the level of information on reproducable bugs.
17:12:08 <itchka_> s/tre/tree
17:13:03 <bero> The problem is that such a tree doesn't exist - that will vary greatly depending on where exactly the problem seems to be
17:13:03 <itchka_> I suppose we could call this a "Triage Chart"
17:14:02 <itchka_> Could such a thing be built up over time?
17:16:19 <itchka_> As each situation presents itself. The point is that people sometimes need guidence and (in my own experience) when a dev gives it is often useful transferrable information which can be applied to other bugs.
17:17:59 <itchka_> As an example of this you and I spent and hour or so trying to debug the intel driver and from that I learn't very valuable information about the X server which I was bale to use to further explore the bug.
17:25:01 <bero> I think it's essentially impossible because a typical user who sees "my application crashed" will probably not even understand what we're talking about when classifying it as "application bug", "driver bug", "library bug" or whatever
17:25:32 <bero> and even for someone who has been working on this stuff for decades it's hard to explain how to tell some of that apart
17:29:58 <itchka_> I agree; I don't think ordinary users will be able or indeed want to do this sort of but QA'ers with some experience could guide them through the process so as to gain the maximum amount of useful info.
17:31:21 <itchka_> Much as you gave me hints on which way to go and I filled in the details it is the same for users but at a less intiuitive level.
17:36:52 <itchka_> Perhaps we should examine this from the user perspective.
17:37:12 <itchka_> Scenario...
17:39:15 <itchka_> A user finds a bug he/she has only just moved to Linux and they hit a problem lets say for the sake of argument that a little box pops up with the url of our Bugzilla and a notice saying please report a bug.
17:41:24 <itchka_> So they go to Bugzilla and sign up and manage to work their way through the process of reporting, finally they manage it and with a great sigh of releif they post the bug. Total time maybe 15 minutes. This is the users investment in the improvement of our OS.
17:42:10 <itchka_> What do you think his/her expectations would be after going through this process.
17:44:58 <itchka_> I think a preliminary acknowledgement would be the first. Perhaps the MoE should start with this response.
17:46:49 <itchka_> The ack could contain a link to a web page explaining our policy on various types of bug. From there perhaps other links could lead to simple tutorials on how to gather information.
17:47:05 <itchka_> Would this kind of approach hel?
17:47:21 <itchka_> s/hel?/help?
17:48:08 <HisShadow> wouldn't it be possible to create a script that gathers information automatically?
17:48:44 <itchka_> We do have one it's called omdv-bug-report.sh
17:49:18 <itchka_> It's a pretty good script produced by TPG
17:57:57 <itchka_> Our link could direct the user to a page explaining the use of this.
18:05:04 <bero> yes, that sounds like a good plan...
18:06:58 <bero> maybe something along the lines of (just more verbose) "Thanks for your bug report, please make sure it has all the information we need (omdv-bug-report.sh), there's various types of bugs (link), we'll take a look and try to help, but we might end up having to wait for a fix from (whoever), because the problem appears to be in their software we're merely using. We'll check with them for a newer
18:08:34 <bero> version that might fix the problem. Please understand that we're a volunteer project without funding, so we can't reasonably be expected to buy specific hardware to try and reproduce a problem not seen anywhere else
18:11:02 <itchka_> I think we have to be careful not just to write off bugs that are potential hardware issues. It's a bit too final as sometimes there is a workaround to the issue.
18:11:51 <itchka_> but we can tune up the wording it's the methods we need to address at the moment
18:13:00 <itchka_> At least we have managed to make a start.
18:14:28 <itchka_> I think the presentation of bugs from the QA team needs looking at too since we should be presentingh full information to the developers which we do not always do.
18:21:20 <itchka_> I am still a little concerned on how we are going to deal with configuration issues what I think we should try and avoid is using the upstream getout clause in every situation I feel it should become a sort of "we don't attempt top fix graphical bugs" type of situation because it will start to look as if we don't care.
18:21:47 <itchka_> should=could
18:22:11 <itchka_> in the last instance.
18:22:55 <itchka_> We are coming to the end of our 2.5 hours of meeting so I think we need to summarise.
18:27:01 <itchka_> I think we all agree that we need to apply some MoE to our bug  triageing/resolution. The best we have been able to come up with so far is to ensure the bugs are promptly acknowledged to the user and that the ack should carry a link to a page explaining our policy with regards to bugs and some further links to diagnostic pages which will help the filer to improve the quality of information that is available on
18:27:03 <itchka_> the bug report.
18:28:26 <itchka_> We have identified the need for canned replies within bugzilla to minimise the time a developer or QA team has to spend replying to bug reports.
18:30:25 <itchka_> Is that an adequate summary?
18:33:35 <ben79> seems OK
18:34:56 <bero> yes
18:35:08 <bero> and we can of course edit the canned replies...
18:35:32 <bero> I do agree that we must not allow ourselves to become "lazy" and just assume everything is a bug we can put into a "let upstream fix it" category
18:35:48 <bero> but in many cases that's what we have to do
18:36:22 <itchka_> I quite understand bero it just needed to be said :)
18:40:42 <itchka_> #share As part of the ongoing QA review this weeks discussion related to triaging bugs. This was a difficult subject but some progress was made. It became evident that the expectations for bug fixes of QA and of users were too high and some effort was needed to explain the level of support that could be offered. Several ideas were floated that would help to address this issue. The first was to provide a link in
18:40:43 <itchka_> the bug acknowledgement mail to a page which explains our policy. This page will untimately contain links to pages that contain information on how to improve the quality of bug reports using tools shipped by OM.  In order to remove some of the load from the developers a series of pre-written (but editable) replies will be made available in Bugzilla to ease the level of work involved in the triaging process.
18:41:48 <itchka_> Ok everyone the meetings over. Thank you all for your contributions. This was a hard one.
18:41:55 <itchka_> #endmeeting