15:37:08 <itchka> #startmeeting
15:37:08 <chwido> Woof! Let's start the meeting. It's Wed Jun 29 15:37:08 2016 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:37:08 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:37:08 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:37:08 <chwido> Have a good meeting, don't bark too much!
15:37:16 <teo-> it's the m-m-m-monster ping
15:37:27 <OnlyHuman> woof woof woof
15:37:48 <oiram73> Hi!
15:38:29 <itchka> Opefully more will gather....
15:38:31 * bero_ barks at chwido
15:38:41 <fedya> i'm
15:38:53 <itchka> #item 1
15:39:05 <itchka> #topic Release Report
15:39:10 <Son_Goku> I've got to go, unfortunately
15:39:14 <Son_Goku> I'm at Red Hat Summit
15:39:23 <itchka> Ok understand
15:39:41 <itchka> bero: Over to you...
15:41:22 <bero_> So things are still looking pretty good from where I stand...
15:41:51 <bero_> beta2 is out, and while we've seen a few bug reports, nothing too serious
15:42:27 <bero_> i586 iso will still be an issue
15:43:01 <bero_> but I wouldn't be too opposed to delaying even the i586 GA past the x86_64 GA, maybe that would even get some people to finally switch to what they should be using ;)
15:43:49 <itchka> bero_: You don't think the patches to binutils will fix things so it will boot?
15:44:16 <bero_> I strongly doubt it because the problem we're seeing doesn't match the problem the binutils patches are supposed to fix
15:44:18 <itchka> I'm still trying to get the kernel built with the new code.
15:44:28 <bero_> our kernel always booted well past "uncompressing kernel" stage
15:45:02 <bero_> so while the fix for that won't hurt and will probably enable a few more devices to boot up to the point where it hangs, I don't think it's the fix for the problem we're seeing
15:45:13 <bero_> but of course I hope I'm wrong ;)
15:45:22 <bero_> and either way the fix is harmless so it can't hurt
15:46:07 <itchka> The reason I found th RH bug is that I booted the kernel by hand and that was the message I was getting. I think there may be some confusion. At the moment iso's build on 3.0 for i586 do not boot at all.
15:46:44 <itchka> iso's built on 2014.3 boot as long as they are the minimal version.
15:47:30 <itchka> There are two different problems. The RH fixes will probably put us aback where we were on 2014.3
15:48:17 <bero_> yes, probably
15:49:27 <bero_> so let's push binutils and kernel from cooker to 3.0 to try...
15:50:47 <itchka> I've been trying to build the kernel this morning but it's broken. It fails with a zero length patch. I've done a local hack and it's buuilding now (locally).
15:51:19 <itchka> binutils from cooker works fine on 3.0
15:51:48 <bero_> is it approved on kahinah already?
15:51:53 <bero_> I don't have a 3.0 box right now
15:52:09 <bero_> no point in pushing the fixed kernel from cooker to 3.0 if the fixed binutils isn't there first
15:52:14 <itchka> I just pulled the cooker rpm onto my system
15:52:49 <itchka> for testing
15:54:47 <itchka> bero: What needs to be done to get to RC?
15:59:37 <bero_> IMO it's mostly a matter of waiting for bug reports to see if we missed anything
15:59:56 <bero_> would be nice to stop qupzilla from crashing on that codec test page and get firefox to play the mp4 videos
16:00:04 <bero_> but not a real must-have
16:00:26 <bero_> we'll also need to either fix install mode on the iso or just remove it
16:01:10 <bero_> and it would be nice if we could fix the calamares partitioner to put /home on a separate partition so people won't take out the guillotines the next time we say installing a new version might work better than upgrading ;)
16:01:27 <bero_> also need to get around to writing the updater for getting 2014.x to 3.0
16:02:19 <bero_> but IMO even that can wait until after RC if it has to (as long as we announce we'll release a script for updating along with the release of the isos for installing)
16:05:10 <joel_tess_> https://issues.openmandriva.org/show_bug.cgi?id=1578
16:05:39 <bero_> TPG was looking into that one yesterday
16:07:05 <itchka> So are we now finished with major updates?
16:07:25 <bero_> I'd say so
16:07:36 <bero_> unless we find a major bug that's fixed with a major update
16:09:10 <itchka> Excellent..I'd say we are well on the way to release. I hope we can fix install mode I don't think it's at all good to remove it.
16:14:12 <joel_tess_> TPG is on it https://calamares.io/bugs/browse/CAL-376
16:17:15 <itchka> bero: I guess we review again if we haven't reached RC point by next weeks meeting.
16:18:46 <itchka> Anything more to say on this item?
16:23:03 <itchka> If not we will move to an item that was proposed to me by _TPG the other day and I said I would introduce so that there could be some information gathering and perhaps later a debat.
16:23:12 <itchka> #item 2
16:24:10 <itchka> #Topic Examine the practicality of using GiHub for reporting issues.
16:26:44 <itchka> I'm sure that those of you who have a GitHub account will be aware that GitHub has an issue/bug reporting interface.  There are also anumber of progress/planning tools that interface with this system. One of them being Waffle.
16:28:24 <itchka> _TPG thought that it might be advantageous to replace Bugzilla with these tools.
16:28:47 <fedya> github for reporting issues cool tool of course, but there is not a list of issues interface
16:28:52 <fedya> i dunno how to manage it there
16:29:06 <fedya> we have >10000 projects
16:29:22 <fedya> and issue tracker available for each project ;)
16:29:25 <fedya> is madness
16:30:04 <fedya> look at example https://github.com/rancher/rancher/issues
16:30:07 <fedya> is good example of course
16:30:21 <itchka> Thank you fedya will look
16:30:25 <fedya> but it's only for ONE project
16:34:33 <itchka> I suggested that access could be through ABF where lists could be be accessed by the project list and this list of issues created there but it's messy. With GitHub issues it is also difficult to impart achitecture information.
16:36:52 <bero_> also we can't really expect a "stupid user" to identify what component he should pick for "I plugged in my camera and that thingy in the taskbar crashed"
16:37:27 <itchka> Indeed :)
16:39:08 <itchka> I wonder if we could use a technique where bugs from Bugzilla are assinged to GitHub issues much in the way they are assigned to Dves?
16:39:44 <bero_> would be a lot of effort, but should be doable
16:39:46 <itchka> bah! It's all coming out backwards today!!
16:40:46 <itchka> Would it bring about any practical benefit thou?
16:41:57 <bero_> I don't think so, it would be just another tool to keep track of if it doesn't replace something else
16:44:16 <itchka> Hmm.. I think there is one benefit it would serve to collect all the bug reports for all the arches against a particular package in one place which conceivably be useful to the development trying to fix it.
16:45:17 <bero_> yes, another benefit would be the (small but non-zero) chance of someone outside our team sending a pull request
16:51:09 <itchka> BTW I think TPG was indicating that we shouldn't perhaps assign bugs to individual packages but more to OpenMandrivaAssociation. Like here https://github.com/OpenMandrivaAssociation/OpenMandrivaLx/issues/3
16:51:37 <bero_> that could work from a user perspective
16:53:19 <itchka> Here is the Waffle interface https://waffle.io/OpenMandrivaAssociation/OpenMandrivaLx
16:53:41 <itchka> It's a Trello like managment board.
16:54:43 <itchka> You DnD by clicking and holding on the red ico at top right
16:57:50 <fedya> itchka what if waffle?
16:58:07 <fedya> itchka if we want to move to github issue tracker, probably need to start from it?
16:59:43 <fedya> e.g. create issue tracker and use it there instead of waffle
16:59:47 <itchka> fedya: Waffle is a tracker I guess. Issues appear in the left column and move to the right hand column when resolved. I shows progress and status.
17:00:10 <fedya> we already have trello, projects.oma, issues.oma, and talking about issue tracker on github
17:00:34 <fedya> i suggest to use only 1 thing
17:01:07 <itchka> Waffle I this is proposed to replace prject.oma becaus projec tis to difficult / complicated.
17:01:31 <fedya> dunno what's difficult there
17:02:05 <itchka> project.oma too complicated / difficult
17:03:47 <itchka> Waffle is more straightforward and can be used for bugs or project plans. It has filters and you can have multiple boards and it interfaces directly with the GitHub api
17:05:10 <itchka> This is just for discussion to explore if there is a better way.
17:07:07 <OnlyHuman> is waffle for a lot of waffle?
17:07:11 <itchka> I'll leave it out there as food for thought.
17:07:57 <itchka> OnlyHuman: Were you dozing I thought you'd be much quicker off the mark with that one :)
17:08:41 <itchka> Lets move onto AOB:
17:08:52 <itchka> #item 3
17:09:00 <itchka> #topic AOB
17:09:16 <itchka> Is there any other business?
17:10:10 <itchka> If not I'll close the meeting in ten minutes mean which I will write the #shares
17:16:26 <itchka> #share Item 1: We are in good shape to move toward an RC candidate there are still some bugs to fix the main one being an issue with Calarmares and libparted. This is being investigated already and it's solution may resolve an issue with the standalone installer entry. i586 booting is still a problem a regression now (hopefully) fixed will allow diagnosis to continue. No further major updates are planned unless
17:16:28 <itchka> they are required to fix a very serious bug. If RC has not materialised before next weeks meeting there will be a further review.
17:21:12 <itchka> #share Item 2: A proposal was made to examine the practicality of using the GitHub issues interface as a replacement for Bugzilla and a tool Waffle for issue progress and basic project planning. The idea has been introduced and further discussion may talke place when the release process has been completed.
17:25:47 <itchka> Meeting will end at 19:30 CEST
17:30:35 <itchka> #endmeeting