15:30:23 <itchka> #startmeeting
15:30:23 <chwido> Woof! Let's start the meeting. It's Wed Jun 26 15:30:23 2019 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:30:23 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:30:23 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:30:23 <chwido> Have a good meeting, don't bark too much!
15:30:30 <itchka> 1. Report: ABF, cooker
15:30:31 <itchka> 2. 4.1 release plan, workflow, milestones
15:30:33 <itchka> 3. What we can learn from the 4.0 release cycle
15:30:35 <itchka> 4. Maintenance of Rolling: Procedure for QA to manage packages. QA
15:30:36 <itchka> training and education
15:30:37 <itchka> 5. Filesystem layout changes
15:30:39 <itchka> 6. AIB
15:30:40 <itchka> 7. AOB
15:31:50 <itchka> I'm going to mess with the order of the agenda because it's too long to cover in one seesion and we need to address some things more urgently than others.
15:32:28 <itchka> bero: ping
15:33:25 <itchka> We will start with 4.
15:33:32 <itchka> #item 4
15:33:56 <itchka> #topic Maintenance of Rolling: Procedure for QA to manage packages. QA training and education.
15:34:42 <ben79> What should I be doing today?
15:37:16 <itchka> A good question. As far as I can see we should be doing nothing different that that which we did for the 2014 release. In other words test everything that is in testing and if it's good release it from testing to rolling.
15:37:32 <itchka> There are the usual caveats of course.
15:39:45 <itchka> We have to avaoid releasing half-finished KF5 libs and possibly kapps as well . How we do this is up for grabs I am hoping Robert Xu will revamp kahinah to work with the rolling repo.
15:42:28 <itchka> We have no means of easily testing the content of libraries so perhaps we should agree on a procedure for these.
15:42:55 * ben79 Kahinah is here: https://kahinah.rxu.tech/  >>> use your github login
15:43:50 <itchka> ben79: Is it connected to rolling yet?
15:44:19 <ben79> look
15:44:56 <ben79> here: https://kahinah.rxu.tech/
15:45:33 <bero> back
15:45:41 <ben79> answer is yet , BUT there are way more packages in testing than there are in Kahinah presently
15:46:46 <ben79> So I can't move most packages that are in Rolling/main/testing anywhere myself
15:46:56 <bero> Hmm, not sure where kahinah gets its package list from
15:47:03 <itchka> Ok ben79 I see
15:47:12 <bero> let me check, maybe it's only packages that were built after kahinah got connected
15:47:31 <itchka> seems likely
15:49:20 <bero> Either way, probably a good list to start with and see if it works...
15:50:08 <ben79> Also what do we do about packages in arches we can't test?
15:51:19 <ben79> This package kernel-rc-5.2.0-0.rc2.1 (x86_64;i686) is older than the package in rolling/main/updates
15:51:22 <bero> Currently, I'd say "if it works on one arch, go ahead and publish" -- we haven't released any non-x86_64 arches yet...
15:51:39 <ben79> should be removed as "succeeded"
15:51:55 <itchka> I tried to list all the stuff that had been published to testing on the rolling repo and it only came up with thres packages for x86_64..Am I missing something?
15:52:08 <bero> yes, let's kill that one, rc6 is much better than rc2
15:52:35 <itchka> thres =three
15:52:50 <ben79> itchka: http://abf-downloads.openmandriva.org/rolling/repository/x86_64/main/testing/
15:54:22 <ben79> bero: itchka: a lot of what is in rolling/main/testing is KF 5.58 packages which should be removed I'm thinking
15:54:43 <ben79> I wish I could remove them myself but don't know how
15:55:23 <ben79> Which brings up does QA need permissions in ABF to do some things like that?
15:57:44 <ben79> bero: and also the 4.0 packages in Kahinah are already in Rock repos so are packages going to Kahinah or through Kahinah?
15:58:31 <itchka> I do have permissions to do this ben79 but I'm not sure of the best way to go about it. Don't want to start deleting files when the repo data is being build.
15:58:35 <itchka> built
15:59:56 <ben79> It looks like Kahinah may be ready to be implemented but hasn't been implemented yet
16:00:38 <itchka> Looks like though everything dated 23-May-2019 is not listed in kahinah
16:00:55 <ben79> And I for one am hoping for a lock so packages have to go to Kahinah/testing and so devs can't move packages directly to updates like has happened so often in the past
16:01:42 <ben79> Robert just made the changes to Kahinah this past weekend
16:01:55 <ben79> Xu_R ^^^
16:04:27 <ben79> bero: itchka: So if someone has permissions to remove package from repo then the need to know and be able to also regenerate metadata too?
16:04:41 <itchka> Well through Kahinah there is some developer control as a package has to be in testing for at least 7 days before they can release it, but there is as yet nothing to stop packages being directly published to main thus bypassing the restrictions imposed by kahinah
16:05:08 <ben79> We need to change that or this won't work
16:06:46 <itchka> Maybe what we should ask Robert to do is to intercept ANY package being published to rolling (and rock)
16:07:09 <ben79> and 4.0 repo
16:07:20 <itchka> That is if the mechanism he is using allows this.
16:08:13 <ben79> I was thinking this would be done on ABF. There would be a lock placed so devs could not build packages to updates repos period. They have to build to testing.
16:08:30 <ben79> or publish to testing
16:09:28 <Xu_R> itchka: abf would need to have some sort of list of approved users to publish maybe
16:09:39 <Xu_R> (kahinah works as a user in abf)
16:09:56 <ben79> Frankly I don't understand why this is not the case in ABF now.
16:11:24 <itchka> fdrt: HisShadow_  Is there any way we can solve this issue?
16:11:37 <ben79> Perhaps it would work in Kahinah, bero and one other dev coulp publish packages to updates repos?
16:11:41 <Xu_R> also while i'm at it, here's my weekly update: last week I enabled kahinah for rolling and 4.0. this week i'd like to dive more into abf, because i have a concern that we should keep this functionality outside of abf and let abf handle builds and builds only. also $day_job
16:13:50 <itchka> XuR: Good to see you around again Robert :) Anything you can do to smooth the path of this would be very much appreciated this has been needed for a v long time.
16:14:34 <ben79> How to do this technically I'm not right person to say, but we have history that tells us what needs to be done.
16:23:19 <itchka> #action The rolling and 4.0 and (by inference rock) repositories should not allow direct publishing to the update repositories ALL packages must reach our users via the testing -> updates path
16:23:57 <itchka> I don't think I can state it any clearer.
16:24:39 <ben79> Well thanks for stating that, if we can't do that we are wasting our time
16:25:31 <itchka> I agree I shall keep plugging away at it until it gets done.
16:25:41 <ben79> I think we need a way for QA to be able to clean up repos of things like redundant or duplicate packages, which I think would mean someone in QA would need to also be able to generate metadata
16:26:57 <ben79> For now we need to get testing repos cleaned up and synced with Kahinah, and get updates locked so only user Kahinah or bero can publish packages to updates IMO
16:27:33 <ben79> So we can start testing in Rolling and start the new Release Process maintenance plan
16:28:35 <ben79> Actually both updates and release repos need to be locked.
16:28:45 <ben79> Since Rolling has no updates repos
16:30:04 <itchka> Yep; I'll work on getting the testing repo cleaned out. Are you saying that packages in rolling testing go straight to the main repo?
16:30:18 <itchka> If released.
16:31:27 <ben79> Depends on where you look, that is something that needs to be cleaned up as well:
16:31:52 <bero> back again, sorry, phone call
16:31:55 <bero> reading log
16:32:27 <itchka> ben79: How so?
16:32:52 <bero> ben79: AFAIK metadata should be regenerated automatically when a package is removed, but rebuilding metadata is easy either way
16:33:02 <ben79> On your system look in this file: openmandriva-rolling-x86_64.repo >>> and there is no updates listed.
16:33:29 <ben79> But if you look here: http://abf-downloads.openmandriva.org/rolling/repository/x86_64/main/ >>> there is updates listed, >>> that updates should be removed IMO
16:34:05 <ben79> or look in znver1 files they should be the same
16:35:02 <bero> Xu_R: Any idea why Kahinah doesn't see all packages in rolling/testing? Does it see only packages pushed after it got connected into it?
16:35:10 <itchka> Ok Ben I see where you are coming from. I think you are right I guess it is only when a a release is made that the update repo is activated.
16:35:34 <bero> yes, updates/ is activated when something is released
16:35:43 <bero> and rolling and cooker by definition shouldn't have updates/
16:35:46 <ben79> itchka: I don't know why Rolling is that way unless because it is well rolling release
16:36:38 <itchka> The reason is because it will be the next release and you can't release it if it's already been released :)
16:36:39 <bero> For a rolling release it doesn't make sense to have a distinction between release and updates (because there are no releases -- what would remain in release?)
16:37:21 <itchka> bero: Thanks for the clearer explanation.
16:39:18 <ben79> then I would suggest we remove all updates repos from rolling forwith
16:39:28 <ben79> forthwith
16:40:23 <HisShadow_> there won't be a need to do that, because rolling will never have a released status
16:40:42 <bero> yes, if there's any updates/ repo that got copied in, we should remove them
16:40:44 <bero> let me check
16:41:53 <bero> deleted
16:42:32 <bero> cooker has updates/ as well, deleting that too, certainly shouldn't be there
16:42:40 <Xu_R> bero: might be date, i set it a month back max to reduce load on abf
16:42:40 <ben79> And then we need to lock all users from building or publishing to any updates and possibly release repos with exception of Kahinah, and bero and maybe one other?
16:42:49 <Xu_R> I can put that back to like 6 months
16:43:12 <Xu_R> if we allow publishing by a human, maybe the 2 person rule might help?
16:43:18 <itchka> HisShadow_: Is there a way we can ensure that publishing on 4.0 and rolling always goes to testing. For proper QA we must prevent any packages being published to main in rolling and updates in 4.0.
16:43:46 <ben79> Xu_R: maybe 2 person rule is good idea
16:44:45 <bero> sounds good to me
16:44:46 <ben79> itchka: HisShadow_; that should be to release in rolling
16:44:59 <ben79> release repos
16:46:03 <itchka> We have the 3 vote rule in Kahinah so are you saying that two poeple have to agrre to publish a package from ABF?
16:46:50 <ben79> I think he meant publishing on ABF itself
16:47:18 <ben79> Which we maybe just should not allow at all, just allow user Kahinah only
16:47:51 <bero> ideally it should just be done through Kahinah
16:47:57 <ben79> any exception we make and you know who will find a way to exploit it
16:48:04 <bero> realistically we should be prepared for outages
16:48:16 <bero> and have some way to get important things done even if something is down
16:48:34 <bero> (or isn't working for whatever reason)
16:48:35 <itchka> Unfortuately I think kahinah polls ABF so packages need to be in a holding area.
16:48:51 <bero> testing/ is the holding area...
16:49:11 <ben79> bero: OK that makes the most sense and is simple. Only user Kahinah can publish to rolling/release or rock/updates, 4.0/updates
16:49:18 <itchka> Exactly
16:49:46 <bero> ben79: yes, would just be good to have an override if and only if kahinah is down or not working
16:50:04 <ben79> Yes agree with that ofc
16:50:37 <itchka> but kahinah can only do that if the package goes through the testing repo so we are back to where we started as far as I can see.
16:50:58 <ben79> NOw this does mean the QA has to get on the stick and do our job on this or developers will be upset to high heaven
16:53:15 <bero> indeed...
16:53:22 <ben79> I forsee one big difference for QA in that testing will take place in Rolling env as very few packages should be going to Rock/4.0 and they will have been tested in Rolling already.
16:53:50 <bero> exactly -- Rock should get only very very important fixes
16:55:15 <ben79> I think I can also say or hope that we can get more people in Rolling and on Kahinah doing this than we had for Lx3.
16:56:34 <bero> yes -- but that should be possible, given Rolling is actually a usable release and 3.0 was just too old to be useful for the last year or so
16:56:47 <bero> we need to make sure we never fall back into a "release never" cycle
16:57:05 <ben79> So when can we get the publish lock done. Need to know because basically as soon as that happens QA needs to get busy with this.
16:57:05 <itchka> bero: What criteria do you suggest for releasing new packages to 4.0?
16:57:55 <ben79> bug fixes, security fixes, Firefox, Thunderbird?
16:58:18 <itchka> Don't you  mean Falkon :)
16:58:19 <bero> itchka: Only serious bugfixes, usually no feature updates (people who want them should use rolling)
16:58:19 <ben79> Or maybe not FF and TBird, don't know about that
16:58:42 <bero> certainly security fixes -- we should never have anyone on a box that has remote root exploits or so
16:59:01 <ben79> So bug and security fixes only except for rare special circumstance?
16:59:12 <bero> yes, IMO that's the way to go
16:59:56 <itchka> I wonder if it's possible to have an rss feed for security stuff on the forums.
17:00:08 <bero> feature updates only if they go with fixing an important bug (e.g. if we had Plasma 5.15 crashing on startup for a large number of users and we know 5.16 fixes it, but we don't know what exactly the fix was, backporting 5.16 might be the best fix)
17:01:00 <ben79> bero: An exception like that should come with about as big an announcement as the release itself I'm thinking
17:01:35 <bero> yes
17:01:56 <bero> or maybe the best fix in that case is simply to make a new release (at that point the rock symlink will move anyway, so...)
17:02:22 <ben79> If we stick to this we really will need to leave or "release never mode" for good as stable will just about have to be upgraded every 6 months or more
17:02:53 <bero> yes, that's really what should happen
17:03:10 <bero> and IMO that's only doable with an actively maintained rolling tree from which we can essentially make a release at any time
17:03:11 <ben79> Though in earlier meeting we discussed doing release base on "milestones" instead of time, but don't recall we defined "milestone"
17:03:32 <bero> we didn't
17:03:47 <bero> so we just have to be reasonable about picking milestones that allow for a release in a reasonable timeframe
17:03:53 <ben79> that's OK for now
17:03:56 <bero> so no "KDE 6.0" milestone for 4.1 ;)
17:04:54 <ben79> For now we need to get QA moving in Rolling and doing active package management, and we need to get that publish lock so only Kahinah can publish to where we discussed
17:05:46 <ben79> We will learn and make changes as we go, but that seems where our starting point is now right?
17:06:16 <bero> yes, IMO it is
17:07:33 <itchka> I feel we should perhaps decide on an arbitary milestone now because we can then group bug reports or other bug reporting mechaisms to build up a picture of the current quality of rolling. As we approach the milestone date we can reduce the throughput of new packages down to those which address existing bugs and onece reduced to an acceptable level we can release.
17:08:32 <ben79> #Action Only kahinah may publish to rolling/release repos, rock/updates, 4.0/updates repos. Exception to be make for emergencies.
17:09:04 <ben79> Um, is that OK
17:09:22 <bero> It's too early because we haven't really decided on a few things yet -- but we already did say we want to release around the time we have Qt 5.13.x, KDE Frameworks 5.59, Plasma 5.16.x and KDE Applications 19.08.x
17:09:35 <bero> but more features to be added...
17:11:51 <itchka> That's fine but that does bring up the point that it seems thjat you would favour a kde release as a marker. This is fine but it does beg the question as to which point release we use.
17:12:14 <ben79> .3 or later
17:12:35 <ben79> for stable release
17:13:23 <itchka> Yes ben79 alongside my thinking but now think of this in context with stabilising rolling..
17:13:27 <bero> yes -- we can make a snapshot release of the rolling tree for the earlier ones (and make an announcement about that)
17:14:43 <ben79> Are we on topic # 2 now?
17:15:00 <itchka> No
17:15:24 <itchka> This is still about how to manage QA on rolling
17:16:57 <ben79> So to do a release at some point we have to stop upgrading rolling for a short period of time. Which will be interesting for this group...
17:17:16 <bero> or at least limit what sort of things go into rolling at that time
17:17:19 <itchka> I didn't say stop I said reduce
17:18:01 <itchka> That's why a milestone is helpful.
17:19:23 <ben79> Yes but we don't need to answer every question today to get started on the release plan maintenance do we?
17:20:31 <itchka> Probably not but we need to have a general picture to mull over.
17:20:46 <ben79> Would it make sense to say set milestones 6 wks to 2 months after most recent release?
17:20:47 <bero> https://community.kde.org/Schedules/Applications/19.08_Release_Schedule -- so we should prepare for a release in late October or November
17:21:18 <ben79> Don't we already have a general picture?
17:21:51 <bero> We do, for the most part
17:22:00 <bero> but of course lots of stuff still needs to be decided
17:22:17 <bero> e.g. the filesystem stuff in topic 5
17:23:07 <itchka> November 7th is the .3 release so sometime after that I guess.
17:24:33 <bero> We have access to the release tarballs as soon as they're tagged, so we can get .3 on November 4th, test it, and be ready for our release along with official .3
17:24:33 <itchka> We do need to moderate the size of our agends a bit.
17:25:48 <ben79> Yes 7 is to many, for today drop AIB with this caveat: there are users on forum with issues that need help for developers (issues I can't help them with)
17:26:09 <ben79> help from developers rather
17:27:15 <itchka> bero: That sounds a trifle optimistic :)
17:27:56 <bero> yes -- something to aim for though
17:30:05 <itchka> ben79: Got any links? I'll try and do a bit later tonight.
17:30:21 <ben79> links for?
17:30:39 <itchka> Forum users needing help?
17:33:00 <itchka> There's a QA training and education part of item 4 I think we should examine that one next week. I'll do an actiuon to carry that forward.
17:33:05 <ben79> You would just go to the forum and look for whatever you want to help with especially: https://forum.openmandriva.org/c/en/support and other suppost forums
17:33:48 <ben79> training and education is going to mostly consist of QA people getting on this channel and asking questions until they get answers
17:34:33 <itchka> #action Item for Agenda to be carried forward. QA training and education .
17:34:36 <ben79> A better way is possible but,
17:36:54 <ben79> did we sort of cover topic 2 already?
17:37:39 <ben79> Workflow: Cooker>Rolling>Rock/Stable
17:38:15 <itchka> Yes I think we have done enough on that.
17:38:35 <itchka> At least for the time being
17:39:33 <ben79> If we wait to long for this topic it won't be fresh in people's minds and discussion may not be useful: 3. What we can learn from the 4.0 release cycle
17:41:25 <itchka> To be ratiional about release planning I think the time has come for us to try and use a project planner again.  I know we tried it before but the online project planner we were using was almost impenetrable regards it's usage.
17:43:29 <itchka> If we had a simple gantt chart of tasks that we could update it would be a great aid to coodinating effort.
17:44:00 <ben79> That is bordering on saying we need to actually put things in writing where other people will see it. Heresy.
17:44:14 <itchka> I know :)
17:44:34 <ben79> We should also revise and use more prominently our checklist for QA.
17:45:27 <itchka> Again this is where the milestone comes in.
17:45:58 <itchka> I have to go in 15 mins so I'll add a couple of extra chairs
17:46:10 <ben79> Going back to previous discussion we need to revise/refine our guidlines for QA for package management also so new QA people aren't trying to figure things out blind.
17:46:10 <itchka> #chair bero ben79
17:46:10 <chwido> Current chairs: ben79 bero itchka
17:47:25 <ben79> Well using kanban board on Github seems to have flopped for project management
17:47:35 <ben79> So we use what?
17:48:25 <bero> we use taiga.io at work - the tool works ok if people actually use it
17:49:47 <ben79> Our problem has been getting people to actually use something.
17:50:22 <ben79> We are so democratic people are used to just doing whatever that want to do and telling others sometimes seems to have become optional.
17:54:27 <itchka> Most of the project management tools I have seen are too complex. They try and do too much. A simple Gantt chart shows you the view of the project and what needs to be done. The kde project tool can work like this. It's not web based but it doesn't have to be for the purpose the chart can be updated by a simple questionaire filled in each week. It could be done at the weekly meeting.
17:54:35 <ben79> As far as I'm concerned anything from a simple "To Do" list or a Gantt chart or taiga.io would be fine if we can just get that one little issue resolved.
17:55:48 <ben79> Maybe updating the chart at weekly meeting would be a step to get people to use it. Except for people like TPG who says "Who uses IRC these days"
17:55:57 <itchka> I'm afraid I'll have to leave you with that one. I have to go now.
17:56:30 <ben79> Don't worry we will have all issues resolved by end of meeting today. Or not...
17:58:08 <ben79> :D
18:27:59 <ben79> Should we wait 5 minutes and do AOB?
18:37:29 <bero> unless crazy and King_InuYasha (and preferably TPG, but he's definitely not here) are around, probably doesn't make sense to talk about filesystem changes
18:42:04 <ben79> I'm not meaning to just arbitrarily stop the meeting it seemed to have stopped itself.
18:42:20 <ben79> And I need to move on to other things.
18:47:39 <bero> Let's stop it then and talk when more people are around... Unless we have AOB
18:51:28 * Xu_R would recommend Zulip with a IRC bridge if we want a modern chat app
18:58:55 <ben79> Xu_R: Maybe, I know nothing about Zulip except what I just read on internet
18:59:03 <ben79> bero: OK
18:59:31 <ben79> #Topic 7. AOB
19:01:07 <ben79> I think we do need something for planning and managing projects, releases, ect. but  we never get past the point of how to enforce that people use it.
19:03:26 <bero> Given we can't really force people to do something, probably it makes most sense for a volunteer to update whatever is in there based on status updates from meetings or so...
19:05:19 <ben79> bero: Yes the best suggestion I have heard is that we start something and update it at weekly TC-Meeting or other meeting should such other meeting start occurring.
19:07:00 <ben79> I don't have preference for what we use at this time. Would need to see something, anything actually used and then we can decide to keep it or switch to something more "cool" or "new" or whatever people want
19:08:48 <bero> agreed, we can use anything...
19:12:10 * Pharaoh_Atem shrugs
19:21:16 <fdrt> bero dnf dist-upgrade it is dnf plugin, right?
19:21:50 <bero> fdrt: Never heard of dist-upgrade... Do you mean distro-sync?
19:23:07 <fdrt> yes
19:33:31 <bero> fdrt: distro-sync is base functionality, no plugins needed
19:34:47 <fdrt> okay
19:35:23 <fdrt> Pharaoh_Atem may you where i can find some docs about writing dnf/yum plugins?
19:36:57 <Izaic[m]> Is 5.16 fully released now? or is it just some components updated?
19:37:03 <Izaic[m]> I'm updating now...
19:51:56 <ben79> #endmeeting