15:15:13 <itchka> #startmeeting
15:15:13 <chwido> Woof! Let's start the meeting. It's Wed Jun  1 15:15:13 2016 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:15:13 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:15:13 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:15:13 <chwido> Have a good meeting, don't bark too much!
15:16:24 <itchka> Here's the agenda.
15:16:27 <itchka> 1. Release report
15:16:29 <itchka> > #share
15:16:30 <itchka> > 1.1 RC and GA release dates and public announcement
15:16:32 <itchka> #share
15:16:33 <itchka> > 2.QA: Pre-Beta2 iso release procedure. Proposal and discussion.
15:16:35 <itchka> #share
15:16:36 <itchka> 3. AoB
15:17:16 <itchka> #ite 1
15:17:23 <itchka> #item 1
15:17:36 <itchka> #topic Release Report
15:18:10 <itchka> bero: You may as well kick off.. Others will see the log
15:18:31 <bero> From my perspective, we're getting ready -- closing out quite a few bug reports
15:19:21 <bero> some others fall into the category we've discussed earlier - problem with a specific piece of hardware, can try to update drivers and file a bug report upstream, but other than that there's little we can do
15:19:41 <itchka> I not sure things are ready enough for another beta.. what do you think?
15:19:56 <bero> one missing bit we can still do before building the next iso is pull in the artwork bits
15:20:05 <bero> I think we're more than ready for another beta when that's done
15:20:31 <bero> I don't think it'll get much better than it is now
15:20:40 <itchka> Do you think we should release those now or keep them for the the RC or final?
15:21:16 <bero> rugyada said the faces should be in the next beta, so at least as far as those are concerned, now
15:22:14 <itchka> That's fine just wondered if anyone wanted toi surprise our public. :)
15:23:20 <itchka> There is still the issue of the i586 iso not building properly.
15:25:05 <itchka> I have reached the conclusion that the i586 version of grub is not working properly and I'm trying to prove it.
15:25:27 <bero> yes, let's take a look at that when the x86_64 iso is ready...
15:25:45 <bero> IMO we shouldn't let i586 delay the rest of the release, we can always release it a couple of days/weeks later
15:25:56 <itchka> bero do you think I would completely break a vm if I uninstalled grub2 and forced an earlier version.
15:25:57 <bero> gives people an extra incentive to just install the x86_64 iso ;)
15:26:07 <bero> shouldn't break anything
15:27:15 <itchka> I'll try progessing down that route. A problem with grub2 does seem to be the only logical conclusion at the moment but we will see.
15:28:56 * n3npq wanders in
15:28:57 <bero> Were you trying UEFI or old BIOS?
15:30:04 <itchka> I tried both. The problem appears to be that grub is not seeing the hd(msdos,1) etc on the iso.
15:30:43 <itchka> As far as I can tell they are on the iso but grub2 i586 just doesn't see them
15:31:40 <bero> Is the config the same as with grub2 x86_64?
15:32:06 <itchka> xorriso reports the eltorito table as being complete and it looks the same for bothe x86_64 and i586 apart from the different naming.
15:33:02 <itchka> I'm going to try and revert to the original 2014 grub2 on a 2014 install and see what that does,
15:34:28 <Pharaoh_Atem> here
15:36:36 <itchka> Hi Pharaoh_Atem
15:36:55 <OnlyHuman> fish? blowfish
15:37:57 <itchka> OnlyHuman: No not blowfish. fish is a file transfer protocol
15:38:44 <Pharaoh_Atem> wait, I thought fish was a shell?
15:38:52 <OnlyHuman> so where in repo?
15:39:00 <OnlyHuman> yes a shell
15:39:00 <itchka> rpm -qa | grep fish
15:39:01 <itchka> fish-1.23.1-3-omv2015.0.x86_64
15:39:17 <OnlyHuman> no fish showing in repo
15:39:18 <itchka> It's in contrib I think
15:40:05 <itchka> Pharaoh_Atem: maybe it's that as well
15:40:43 <itchka> it's as old as the hills
15:41:35 <OnlyHuman> found it thanks
15:42:14 <itchka> if you just did 'urpmi fish' it should have found it.
15:42:15 <OnlyHuman> why doesn't it get pulled in if needed?
15:43:24 <itchka> On the latyerversion of parallel I have set it as a Requires so it should be.
15:46:23 <bero> I'll take a look at the i586 iso when I have a bit of time. Should boot in VirtualBox, right?
15:47:29 <itchka> No problem at all
15:48:37 <itchka> In theory it should boot in EFI mode too
15:55:17 <itchka> bero: best use my version of omdv-build-iso. The current one doesn't work because of all the name changes. In fact I should pull mine into master. I do that later tonight
15:55:46 <bero> itchka: let me know when you've pushed it, will take a look then. I have some other (work) things to do first anyway
15:57:17 <itchka> Ok no prob
16:03:09 <itchka> So we need to set some timings for the beta/rc. Any ideas?
16:03:18 <proyvind> bero: could you merge this one: https://github.com/OpenMandrivaAssociation/perl/pull/1/commits/c1034b60b11516f35df00a68d1dbf20aea095188
16:03:56 <proyvind> or someonesomeonewhoever
16:04:05 <bero> proyvind: sure, looks right.
16:04:29 <proyvind> thx
16:05:14 <bero> proyvind: done, thanks
16:05:48 <bero> itchka: I'd say "as soon as possible"... Do we want to make the i586 iso delay the beta release or should we just release x86_64 first?
16:07:51 <proyvind> bero: I've opened up most of my repos again a while back (if there's anyone missing, lemme know), related to, I really think you'd like to merge this one: https://abf.io/mandrake/rpm/commit/f6cf19eb7420cf65efce617b01f07fb56ee0bcdd
16:09:21 <itchka> Well I would favour getting an X86_64 Beta out asap. Unless of course i586 gets fixed tonight. What say you we give it till midday tomorrow and if it's not fixed by then then we make an x86_64 iso for a quick QA check and then release it maybe Saturday or Sunday
16:10:18 <bero> itchka: sounds good
16:10:25 <bero> proyvind: yes, that looks good...
16:11:47 <itchka> Ok bero we will go with that
16:12:14 <OnlyHuman> n metadata found lx3 build?
16:12:32 <OnlyHuman> oh you were moving repo again?
16:13:23 <itchka> OnlyHuman: Yes it's now 3.0. I'll send you a fixed up rpm. Mean't to do it this morning but life intervened
16:13:43 <OnlyHuman> itchka: ok thanks
16:14:16 <OnlyHuman> maybe will get something to actually build then, anbd hopefully better than last time
16:17:58 <proyvind> bero: you might wanna switch to perl-URPM branch at https://abf.io/software/perl-URPM/ (rebased on mageia's repo, same reivisions all up to last shared commit, with all commits of ours since applied to) and apply the couple of commits from your bracg lacking from as well
16:18:35 <proyvind> same goes for everything under /software that all of has been reopened as well
16:19:52 <itchka> Ok lets move on
16:20:09 <itchka> #item 1.1
16:20:45 <itchka> #topic RC and GA release dates and public announcement
16:22:27 <proyvind> especially https://abf.io/software/spec-helper/commits/master has several changes that might be nice
16:23:50 <bero> proyvind: thanks, will definitely take a look, I'm just a little scared of merging bigger changes this late in the release cycle. We need to make absolutely sure it doesn't break things...
16:24:39 <proyvind> bero: you've (supposed to have) been late in the release cycle for quite a while now, haven't you :p
16:26:25 <itchka> bero: I think we can only get a good idea on this when we see what's with the next beta.
16:26:59 <bero> yes, me too
16:27:18 <bero> proyvind: true - that's why delaying it even longer would be pretty bad.
16:28:48 <itchka> I assume there are no more nasty surprises like libpci kicking around. So the best we can say here is  "We will review after the next beta release"
16:29:58 <itchka> bero: Is everything done now with regard to repo naming and the like?
16:30:59 <bero> itchka: yes, looks like all is good. Need to make sure by actually building some things on the 3.0 branch, but not expecting problems
16:31:45 <itchka> I have buillt several test isos from it and they all worked.
16:32:26 <itchka> Ok I'll do a share to that effect.
16:38:58 <itchka> #share The release is entering the final stages of readiness. The repo's have now been renamed to 3.0 and are accesable on abf-downloads. It still remains to fix i586 booting but if this cannot be fixed promptly then an x86_64 beta with be released sometime over the weekend. Bug reports against this beta will determine whether an RC is required or whether we go straight to release. There are still issues with i586
16:39:00 <itchka> booting but it has been decided to release an x86_64 Beta regardless of the state of the boot issue. Hopefully though it will be fixed and both arches will be issued together.
16:39:18 <itchka> Ok next item
16:39:22 <itchka> #item 2
16:39:50 <itchka> #topic QA: Pre-Beta2 iso release procedure. Proposal and discussion.
16:40:42 <itchka> This one is me
16:41:45 <itchka> I'd like to propose that after the pre-release beta is issue to QA  QA will do the following.
16:45:10 <itchka> 1. We will review the iso. A minimum of two days is required for this. No major updates should take place during this time; we cannot effectively test a moving target. All updates should go to the testing repo. At the end of the test period QA will produce a report and a recommendation.
16:47:11 <bero> sounds good to me
16:47:13 <itchka> The recommendation will be reviewed by the cooker devs to see if there is a reasonable basis for the recommendation.
16:48:27 <itchka> This would probably only be necessary if the recommendation is to reject.
16:50:53 <itchka> I believe that QA still needs the power to reject but perhaps we can make it a more productive process by trying ti this way.
16:54:11 <christann> I presume that QA will have some criteria for acceptance and rejection.
16:54:30 <proyvind> bero: obviously, just hard not to poke fun at ;p
16:54:47 <itchka> QA's focus is on the experience that we give the user when they use our distro and this always leaves us with the conundrum of what a developer sees as just a little niggle is actually a massive issue to an inexperienced user. I believe it's that balance that we need to get right.
16:55:16 <ben79> Indeed
16:55:30 <ben79> I'm learning...
16:55:54 <itchka> christann: Thsi has been deiscussed at some length in previous meetings and there is still some more discussion to be had.
16:56:11 <christann> Okay
16:57:10 <joel_tess> file a bug is mandatory during the test period (especially in case of NO), no mailing list please
16:58:01 <bero> itchka: agreed, that seems to be the right way to go
16:58:03 <itchka> christann: We have come to some agreement over graphics adapter bugs and I hope that we will be able to use the criteria we developed to good effect.
16:58:10 <ben79> Sometimes we post on mailing list to be sure if an issue is really a bug not something else
16:58:20 <ben79> Same on Forum
16:58:53 <christann> itchka: sounds good.
16:58:55 <ben79> But joel_tess is correct about filing bugs
16:59:10 <itchka> ben79: You mean bugs that are actuially misconfigurations.
16:59:26 <ben79> Yes or stupid mistakes etc
16:59:43 <ben79> Not that I ever make a stupid mistake
17:00:00 <ben79> Or a dumbass configuration
17:00:50 <ben79> :)
17:00:58 <itchka> You are not alone there ben79 :) I think the problem arises when we are not sure whether it's configuration or otherwise. This is where triage comes in.
17:01:41 <itchka> and that ios part of the ongoing discussion we are yet to have.
17:02:38 <ben79> Yeah
17:04:21 <itchka> I don't know the best way to approach this to get the maximum effect for the minimum of effort. In my view the configuration of a basic system could be done to a simple check list.
17:05:32 <itchka> If the list isn't too long then a user could just go from top to bottom rather than trying to diagnose precisely what is wrong.
17:05:59 <itchka> Which is whilst fun also very time consuming.
17:08:52 <itchka> TPG created the omdv-bug-report script which should always be used by triagers to aty least do a basic analysis on the system configuration.
17:09:28 <ben79> It seems it would clarify things is we had a check list for testers to use also check list for bug triage
17:09:51 <itchka> Using it requires no skill from the user and it provides alot of useful information.
17:10:48 <itchka> There is a checklist for testers which I drew up on our QA site
17:11:08 <itchka> I'll post the link
17:11:50 <OnlyHuman> it is frustrating for users when  stuff simply does not work
17:12:37 <OnlyHuman> which unfortunately for some is often the case
17:16:07 <itchka> ben79: https://docs.google.com/document/d/1ohi4Sf4Tw3tFBQDJVj4VXBRpTyR_u5giGCmKo-R111g/edit?usp=sharing
17:18:34 <itchka> I think a triage procedure would also be appropriate but we would all have to get together on this and we would definately need help from the dev community to be able to come up with a useful document. I'm willing to try and produce an outline which we can flesh out with consultation.
17:19:04 <ben79> itchka: Thanks
17:19:10 <itchka> ben79: Please feel free to edit and improve the testing doc.
17:19:13 <christann> Good idea
17:19:49 <ben79> Triage procedure good but will need input from developers
17:20:12 <ben79> I gotta go to Dr.
17:20:37 <ben79> Does Louisiana Spine and Pain Clinic sound ominous enough...
17:20:39 <itchka> ok ben79.
17:20:53 <christann> ben79: good luck
17:20:55 <ben79> will read logs after I get back
17:21:08 <ben79> Thanks'
17:21:23 <ben79> bbl
17:21:26 <itchka> #action itchka to outline triage doc for discussion/improvement.
17:23:41 <itchka> I don't have anything more on this one at the moment; does anyone else have anything to say on this subject?
17:29:06 <itchka> Ok lets move on
17:29:13 <itchka> #item 3
17:29:31 <itchka> #topic Any other Business
17:29:38 <proyvind> yeah
17:29:55 <proyvind> what position does people have on the us election? ;p
17:33:40 <itchka> Pharaoh_Atem: Is it alright if I give you a spot on next weeks agenda?
17:33:58 <Pharaoh_Atem> about what?
17:34:25 <Pharaoh_Atem> the dnf stuff? sure
17:34:44 <itchka> Ok consider it done.
17:35:42 <proyvind> got libsolv/hawkey issue resolved?
17:36:31 <itchka> Ok I'm gonna close the meeting now as I have to feed the troops. Meeting will close at 19:40
17:41:17 <itchka> #endmeeting