16:03:41 <itchka> #startmeeting
16:03:41 <chwido> Woof! Let's start the meeting. It's Wed Jul 31 16:03:41 2019 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:03:41 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:03:41 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:03:41 <chwido> Have a good meeting, don't bark too much!
16:04:04 * bero barks at chwido
16:04:50 <itchka> Here's an agenda
16:04:52 <itchka> 1. Working as a group
16:04:54 <itchka> 2. Getting off github
16:05:01 <itchka> #item 1
16:05:13 <itchka> #topic Working as a group
16:05:26 <itchka> Who is going to head this one?
16:10:05 <itchka> Ok here's a statement "A succesful group is where all the indiviuals within it are subservient to and agreed goal" Discuss
16:10:15 <itchka> and =an
16:14:12 <ben79> I'll add something: This issue came up because currently have a problem with someone making basic fundamental changes without first discussing and gaining agreement with the contributor group. (TPG mainly.)
16:15:44 <itchka> ben79: Was this the business about ipw?
16:15:58 <ben79> That is one example.
16:18:07 <bero> you mean iwd?
16:18:39 <itchka> I knew it was something like thta :)
16:18:41 <bero> It was iwd and a kernel patch that broke another one (MuQSS breaking binder), and possibly a few other similar things
16:19:06 <ben79> This is another example: https://github.com/orgs/OpenMandrivaAssociation/projects/3
16:20:13 <ben79> while there is nothing wrong with having such a board it is wrong IMO to post things there and assume that everyone else is in agreement and then make changes on that basis. These issues should be discussed and agreed upon by the group.
16:20:19 <itchka> This has been a perennial problem why TPG can't just do this stuff on cooker instead of polluting working releases is beyond me.#
16:20:41 <bero> The board is a good thing IMO, but surprising everyone else with it wasn't that good
16:21:00 <ben79> itchka: even on cooker changes should be discussed first then done not the reverse which is currently what is happening.
16:22:35 <ben79> bero: I was baffled that no one else uses the board. But I'm also baffled why TPG thinks once he has written on the board then that is etched in stone and OK to change without discussion.
16:22:51 <itchka> bero: That board immediately makes the assumption that the items in the lists need to be done. There is no acceptance process prior to their appearance on the "todo" list.
16:22:57 <ben79> Don't think that is best way for the distro.
16:24:09 <ben79> There is also this which also by itself is not wrong, but the way it is being used is wrong: https://github.com/OpenMandrivaAssociation/OpenMandrivaLx/issues
16:24:10 <bero> itchka: true, but the items on it were in fact mostly copied from an ML discussion
16:24:34 <itchka> There should be something called an "impact analysis" before it's get on that list.
16:25:52 <ben79> Things on the "To Do" list should either be discussed or at least announced in TC-Meeting so other people are aware and have a chance to weigh in if they disagree.
16:26:11 <bero> https://forum.openmandriva.org/t/cooker-ideas-and-brainstorming-for-cooker/2890 <--- this is where most of the stuff in there originated
16:26:33 <itchka> I mean the iwd thing seemed to cause issues because it only happened to work with the hardware that the individual who decided to ship it had.
16:27:11 <itchka> An impact analysis would have identified that the change may have hardware depdndencies.
16:28:20 <ben79> bero: Then we should say publicly (like in TC-Meeting) that the Kanban board is official and everyone should use it and follow it. So people know to look there and say "No" to things they disagree with.
16:28:46 <ben79> There is nothing at all wrong with having the Kanban board, I think it is a good idea myself
16:28:59 <ben79> but it should not be a one person show
16:29:11 <bero> My only problem with it is that it's hosted on github (for problems mentioned before), we should probably have put it elsewhere and we should still be prepared to move it elsewhere
16:29:44 <bero> Indeed, I think right now it is mostly a one person show because some people are more upset about creating it without first discussing it than I am
16:31:22 <ben79> For instance the iwd issue is on the Kanban board as "In progress" when others have suggested that is not the best thing to do at this time, or the best way to do it.
16:32:41 <ben79> Also such "I disagree" would need to be a dev not someone like me or they won't be listened to.
16:33:15 <bero> I think we have a good solution for the iwd issue (just needs to be finished 100%)
16:33:37 <bero> Enabling it at build time is a good idea so people who want to can start testing and using it
16:33:45 <bero> But it should be disabled by default at runtime for now
16:34:03 <bero> At least until we have some confirmations of it actually working on non-Intel hardware
16:34:50 <ben79> I'm not really wanting to discuss the iwd issue rather the issue of making such changes without group agreement as seemed to happen in this instance.
16:35:29 <itchka> It does beg the question though bero though is this change for changes sake. Replacing something that has worked adequately for years with somethong that appears to have limited fuctionality.
16:35:41 <itchka> Why
16:36:36 <bero> wpa_supplicant works well but is rather crappy
16:36:37 <itchka> The same with split usr to merged-usr. What's the point...
16:36:47 <bero> There were good reasons for starting iwd
16:36:51 <bero> see e.g. https://lwn.net/Articles/770991/
16:37:20 <itchka> works well but rather crappy is a bit of a contadiction :)
16:38:23 <bero> Not really... A house without a roof works quite well until it starts raining
16:38:58 <bero> And there are a few GTK applications that work fairly well despite the fact that they're built on a foundation that couldn't be any worse
16:39:22 <bero> DrakX worked well, but ask anyone who has looked at the code if it's crappy ;)
16:39:36 <itchka> At the risk of being pedantic is a house without a room a house :)
16:39:53 <itchka> room-roof brains failing
16:41:12 <ben79> Well, to me the issue is are we discussing changes like this and agreeing on them in TC-Meeting or not? Are we just all free to write something we want on Kanban board (Or Github Issues) and then just do it with no discussion among contributors?
16:43:53 <ben79> The other problem with Github issues is the reporting of bugs in 2 locations, which is confusing and IMO also wrong.
16:44:53 <bero> IMO it varies... If it's a small change (like "Update vim from 8.0 to 8.1"), no need to discuss and agree because it's a no-brainer anyway -- but for bigger changes there should be some discussion before putting it on a todo list
16:45:03 <bero> This would be e.g. IWD and the various filesystem changes proposed
16:45:17 <bero> but of course there's a gray zone in between
16:45:41 <rugyada> reference: https://wiki.openmandriva.org/en/Policies/Repository_Policies
16:45:54 <ben79> Github issues: Note that all but one bug was opened by the same person, I opened the other one.
16:46:54 <ben79> bero: Yes, good point and one I've thought about, most people don'
16:47:14 <itchka> must go for a few minutes
16:47:49 <ben79> bero: Yes, good point and one I've thought about, a lot of times people don't discuss upgrading a package version for instance, somethimes, like glibc we should
16:48:18 <ben79> dbus, system and tool chain packages and yes even in cooker
16:51:58 <ben79> And the real issue now is that we do have written policies here: https://wiki.openmandriva.org/en/Policies/Repository_Policies
16:53:11 <ben79> And we need agreement that we will follow those policies and some enforcement if people don't follow. (the iwd is an example where the policy as written was not followed.)
16:54:18 <ben79> We also need the agree/disagee about using the Kanban board and Github issues.
16:54:50 <ben79> I'm in favor of Kanban board if "everyone" uses it. I'm skeptical or against Github issues at this time.
16:54:57 <crazy> ben79: bero there need be just ONE place not like 5
16:55:19 <crazy> ONE used by all
16:55:28 <ben79> crazy: yes that is making the point better than I have
16:56:10 <ben79> For instance things can go on Kanban board after they are decided in TC-Meeting.
16:57:19 <crazy> ben79: it does not matter which it is the problem is we got bugziall, forum-like-cooker-board , TC meeting ( some ignores anyway ) , github <whatever that is> and what else ?
16:57:28 <crazy> *bugzilla
16:58:01 <crazy> now if you dicide to not like any of the above you go and create something new for yo or what ?
16:58:13 <crazy> the point it each instance bypasses the other
16:58:48 <rugyada> Kanban board should be mirrored/backup-ed too just in case, or not?
16:58:49 <ben79> Yes, and I agree to resolve this we need one place only for making decisions. (I would suggest TC-Meeting OR Cooker ML but not both.) I lean towards TC-Meeting.
16:58:56 <crazy> so no matter what way we go there has to be just ONE instance of handling bugs,todo's, milestone's etc
17:00:41 <crazy> rugyada: I don't know all I know is I personally am *against* github as issue tracker of any sort ( and no not bc the recent issues with github but in general )
17:01:31 <crazy> I mean we own infrastructure already , servers , domains etc .. is not like we could not host all
17:01:47 <rugyada> I was neutral till now, now I would be against because of the latest bad news
17:02:02 <bero> same here
17:02:22 <ben79> Bugzilla was established as our "Issue Tracker" at the inception of OpenMandriva and as far as I know that has not changed. There has been no decision involving QA to use something else.
17:02:25 <bero> I'll try to get another public IP from my ISP, then hosting shouldn't be an issue anymore
17:02:31 <bero> Plenty of underutilized boxes here
17:02:37 <crazy> with the situation now is a no-go anyway
17:02:51 <bero> But even then we need to decide what to use
17:02:59 * ben79 Though I agree Bugzilla is not perfect, it exists and it does work.
17:03:11 <itchka> You might like to take a look here.. https://www.scrumexpert.com/tools/scrum-kanban-open-source-tools-for-bugzilla/
17:03:19 <crazy> bero: I don't know .. whatever it is we should have control over it
17:03:33 <bero> exactly
17:03:51 <rugyada> agreed on host our own stuff as much as possible
17:04:37 <rugyada> and when not possible, to choose the most reliable open source services
17:04:53 <rugyada> independent and agnostic
17:04:54 <crazy> rugyada: 2 things these days .. host your own code && your own issue tracker .. website is not auch a big problem to outsource in a cloud instance somewhere
17:05:00 * ben79 itchka: Yes that looks interesting, very interesting.
17:05:15 <crazy> if you loose your code and cannot control your BTS/BOARD you stuffed
17:06:46 <rugyada> sure
17:12:08 <itchka> I'd favour a kaban board in Bugzilla. We have Bugzilla V5 and there's a standard plugin for it.
17:12:33 <itchka> https://github.com/leif81/bzkanban
17:13:11 <itchka> Question will the whole world desert github?
17:14:40 <ben79> So we can discuss things on Cooker ML and/or TC-Meeting but issue becomes official when announced in TC-Meeting? For bugs, boards, To Do lists, milestones, etc. we use existing bugzilla?
17:14:58 <rugyada> anyway it's not like the bug traker topic has not been discussed before https://forum.openmandriva.org/t/issue-bug-tracking-system/2183
17:14:59 <rugyada> just the discussion did not get a true outcome
17:15:01 <rugyada> but without a decision I'd suppose we must keep the status quo until further discussion/agreement
17:15:56 <ben79> Yes, the bug tracking issue has been discussed more than enough and Github did not gain any traction.
17:16:12 <rugyada> and here we go again back to the personal initiatives without any agreement
17:16:44 <ben79> Our bugzilla was and remains the "Official" Issue Tracker for OpenMandriva, that is not and should not be in dispute at all.
17:19:04 <ben79> And my understanding was and is that TC-Meetings are where "Official" decision making is done for OpenMandriva.
17:20:12 <rugyada> +1
17:20:32 <AngryPenguin> imo, we should still use bugzilla as official issue tracker and try add to it also TO-DO-LIST
17:20:52 <AngryPenguin> decision should be made in tc-meetings and discused in ML\
17:22:27 <bero> +1
17:23:46 <itchka> +1
17:24:18 <rugyada> AngryPenguin:  discussed in ML and decided/officialized in TC meeting :)
17:24:35 <AngryPenguin> yes
17:24:38 <rugyada> meeting has logs
17:24:38 <ben79> OK, now for the next step. We need to get TPG, and anyone actually, to follow this the same as everyone else.
17:25:04 <rugyada> back to itchka's definition request
17:25:06 <rugyada> to me "A succesful group is where people speak each others, discuss topics, agree or live with majority's decisions"
17:25:07 <rugyada> lone wolves just bring chaos and disappointment when not anger to the point of some guys may decide to leave the project
17:25:08 <ben79> Officialized in TC-Meeting has the advantage of being published and available to the public.
17:25:50 <ben79> rugyada: Yes, this affirms itchka's original thesis IMO
17:25:51 <rugyada> ben79: exactly
17:26:05 <rugyada> ben79: yes
17:28:17 <ben79> So to be clear we are essentially affirming that we continue with what and how we have been doing with the addition of making some changes to our bugzilla. That is adding a board for "To Do" list and for tracking progress of that list. Like a Kanban board or something similar.
17:28:30 <bero> +1
17:28:55 <ben79> But we have not answered how to enforce this if someone does not follow the accepted path.
17:29:05 <rugyada> the point now is what to do when/if-ever one lone wolf keep doing wth he wants without any agreement
17:29:13 <rugyada> ben79:  lol
17:29:46 <bero> Right -- that's the tough one
17:30:15 <bero> We could block accounts or revert changes even if they're good, but of course that would be punishing everyone
17:30:29 <bero> So it would be good to have a better option
17:31:02 <itchka> A formal request to revert the changes. Polite but firm.
17:31:29 <itchka> If necessary with an explanation why the request has been made.
17:32:25 <ashledombos[m]> Hi
17:32:42 <bero> Hi ashledombos[m]
17:32:43 <ben79> itchka: +1
17:33:12 <ben79> Hi ashledombos[m]
17:33:48 <itchka> If we circulate the decision of this meeting written formally so there is no confusion or misunderstanding then there can be little argument. We could even suggest the the change be submitted for thew proper review process.
17:34:24 <bero> yes, makes sense
17:34:31 <ben79> +1
17:34:56 <rugyada> revert is not a problem if the changes are not good. but even if they are good the person need to get that changes as per https://wiki.openmandriva.org/en/Policies/Repository_Policies have to be discussed.
17:35:18 <bero> yes -- what do we do in that case?
17:35:23 <ben79> there should be a step before revoking privileges, but that should come in to play for multiple offenses.
17:35:37 <bero> Force the person to watch the latest Bush speech as a form of torture? ;)
17:35:56 <rugyada> bero:  +1 :D
17:36:33 <ben79> Listen to Boris Johnson speech?
17:36:40 <itchka> We advise teh individual that their changes have been submitted for review stating the date of the review and invite them to attend.
17:36:42 <rugyada> revoke privileges for a given time maybe better
17:37:59 <ashledombos[m]> Hi, just as a remind we had started a kanban in github
17:38:18 <ashledombos[m]> it appears not to be used
17:38:33 <itchka> ashledombos[m]: How do we access it?
17:38:33 <ben79> I think for first offense written notice but using the individuals name so no mistaking, then revoke privileges for some period for second offense, longer for 3rd offense and banning for 4th offense. Something along these lines.
17:38:54 <rugyada> and/or to write the name/date/reason into a public board.  something the bad guys at school :P
17:38:58 <ashledombos[m]> But i think if ever we choose to use github for kanban, i'm strongly in favor of openmandrivasoftware
17:39:31 <ashledombos[m]> itchka https://github.com/orgs/OpenMandrivaSoftware/projects
17:39:43 <bero> ashledombos[m]: https://github.com/orgs/OpenMandrivaAssociation/projects/3 It is there, but we need to get off github -- may be good to read the channel log
17:40:52 <ashledombos[m]> bero: this one is tpg's one, not the one we started to try with ben79, rugyada etc
17:41:21 <ashledombos[m]> Though i'm not sure which one was started first
17:41:27 <ben79> Yes, we have basically agreed to setup a board in bugzilla, (Github is being banned over time.)
17:41:30 <ashledombos[m]> And i agree about github
17:41:42 <ashledombos[m]> Especially since their new politics
17:42:12 <ashledombos[m]> Banning countries US don't like… or regions such as crimea
17:43:27 <ashledombos[m]> Btw as asked before, i also made this for testing https://code.openmandriva.org
17:43:29 * ben79 We can't have mighty, powerful, Linux coders threatening the Kingdom of Orange.
17:43:41 <crazy> +1 from me for bugzilla/BTS/TODO
17:44:07 <ashledombos[m]> For instance this is a repo mirrored from github
17:44:30 <crazy> sry guys but after taking these pills I have a hard time in from of the monitor :/
17:44:53 <ashledombos[m]> I think crazy has much more skills in git magic than I, and maybe could help mirroring all org
17:45:16 <ashledombos[m]> Sorry for you crazy take care
17:45:36 <itchka> Look after yourself crazy
17:45:48 <ashledombos[m]> The mirrored repo: https://code.openmandriva.org/Software/om-repo-picker
17:46:02 <bero> ashledombos[m]: yes, we were talking about that earlier -- certainly need to at least be prepared to move off github. I'm trying to get my ISP to get me another IP so we can host some more stuff for free
17:46:03 <crazy> ashledombos[m]: once we know what we do we can work out some git hooks to mirror to some other place
17:46:40 <crazy> bero: itchka guys we can do the translation to own git in the next freeze time
17:46:55 <crazy> means near zero delay or zero delay for the matter
17:47:22 <bero> I want to do a mass build soon-ish to see how well LLVM 9.0 does -- that could be a good time to work on this...
17:47:45 <ashledombos[m]> Remember abf is tied to github
17:48:01 <bero> yes, but rosa's abf isn't
17:48:08 <bero> so chances are we can restore that easily
17:48:10 <ashledombos[m]> So fdrt or HisShadow skills are necessary
17:48:21 <crazy> bero: the most delay is to clone all repos including history & branches .. but that means we need freeze all for this
17:48:40 <crazy> bero: so the freeze time is perfect for that
17:49:01 * ben79 So let's come up with some #Action's for using TC-Meeting and Bugzilla and another #Action for enforcing this?
17:49:04 <rugyada> I'd suggest no more hesitation and start migration process instead asap
17:49:08 <crazy> bero: until then we can decide what to use and where to host and setup scripts hooks, prepare ABF code ?
17:49:19 <bero> crazy: makes sense
17:49:35 <ashledombos[m]> Cool
17:49:58 <crazy> bero: so then is a matter of ./run-clone-script , ./run-remote-delete-script , ./run-setup-mirror-script , ./switch abf
17:50:07 <bero> right
17:50:59 <ashledombos[m]> Bero maybe if we stop to pay servers, we can use money to buy UPSs units?
17:51:16 <bero> ashledombos[m]: that would definitely be good
17:51:22 <rugyada> +1
17:52:00 <ashledombos[m]> Well all depends on your home in fact, i know it's quite heavy
17:52:29 <ashledombos[m]> So if it's in a attic with wooden floor…
17:52:34 <bero> The only requirement from that side is that it can't be too loud ;)
17:52:59 <bero> Can't use my OpenPOWER box because its fans are so loud they scare the dogs away
17:53:27 <ashledombos[m]> sure
17:53:37 <bero> I currently have a stack of 4 towers sitting next to my desk
17:53:41 <bero> along with a 16-port hub
17:53:51 <bero> and a couple of devboards of course
17:55:13 <rugyada> ben79:   yes, need action, agreed and the likes
17:55:22 <ashledombos[m]> Btw tpg was not wrong on the fact github has almost no downtimes
17:55:57 <ashledombos[m]> While hosting has the issues we have faced
17:56:35 <itchka> Can we please plan this migration properly there's plenty of time. To do limited testing to assess the impact. Disruption to ABF should be at a minimum.
17:56:39 * ben79 And we should do an #Action on transitioning from Github also?
17:57:35 <ben79> Or should Github issue remain under discussion until we can be specific about what we are going to do?
17:57:55 <rugyada> itchka:  as I understand we do have backups and mirrors
17:58:04 <ben79> Maybe and #Action on Github stating that the status quo is unacceptable or something?
17:59:29 <ben79> Proposal: #Action TC-Meetings will remain the Official place for decision making for OM the distro. Discussion of issues to take place both in TC-Meetings and on Cooker ML but decisions are not Official until so stated in TC-Meeting.
17:59:31 <ashledombos[m]> Ben79 apparently we did not take policy decision yet
17:59:31 <itchka> What should be avoided at all costs is unplanned gung-ho changes to our infrastucture without properly assessing the consequences.
17:59:57 <ashledombos[m]> As usual we slip to technical discussions 😁
18:00:45 <ashledombos[m]> ben79 fine with me
18:00:47 <itchka> I would suggest that this change be treated in the same way as a major change to the distro would be treated.
18:01:03 <itchka> i.e. A proper "Imapct analysis"
18:01:08 <itchka> Impact
18:01:27 <ben79> Proposal: OM Bugzilla will continure to be used for ALL bug reporting and will be expanded to include tools like a Kanban board for "To Do" lists and for tracking progress of such "To Do" lists. Also OM bugzilla will be the place for any other things like establishing milestones, ect.
18:01:30 <ashledombos[m]> Ben79 do we have then a page with to-do (accepted to do)?
18:02:19 <ben79> Proposal: #Share Github will not be used for reporting bugs, issue tracking, or any kind of Official lists.
18:02:26 <ashledombos[m]> Shouldn't we test kanban in bz before?
18:02:33 <bero> yes
18:02:35 <bero> definitely
18:02:44 <ben79> ashledombos[m]: no they would need to be created.
18:03:03 <itchka> ashledombos[m]: To get this we will have to add an extension such as may be found here. https://www.scrumexpert.com/tools/scrum-kanban-open-source-tools-for-bugzilla/
18:03:48 <ashledombos[m]> Imho it's a whole move. I'm not sure yet of the best choice (bz, issues in, let's say, gitea etc)
18:04:22 <ashledombos[m]> itchka i'm in favour of testing if possible before
18:04:23 <ben79> No bugzilla is and has been used Officially by OM for bugs since our inception.
18:05:02 <ben79> Testing a Kanban board is appropriate, but we aren't going to use Github for that.
18:05:06 <ashledombos[m]> Yes i don't say it's not the case
18:05:09 <itchka> ashledombos[m]: Not just testing but proper pre-planning.
18:05:32 <ashledombos[m]> I'm not talking about github
18:05:50 <ashledombos[m]> But if we host our code (gitea, pagure, gitlab etc)
18:05:59 <ben79> This one is agreed then? Proposal: #Action TC-Meetings will remain the Official place for decision making for OM the distro. Discussion of issues to take place both in TC-Meetings and on Cooker ML but decisions are not Official until so stated in TC-Meeting.
18:06:05 <ashledombos[m]> It also has tools
18:06:08 <itchka> I think we are talking at cross-purposes I was talking about the move from github with regards planning and acceptance.
18:07:05 <rugyada> ben79:  agreed
18:07:07 <ben79> And this should be agreeable? Proposal: #Share Github will not be used for reporting bugs, issue tracking, or any kind of Official lists.
18:07:32 <crazy> yes
18:07:34 <crazy> +1
18:07:47 <ben79> This should be agreeable? Proposal: OM Bugzilla will continure to be used for ALL bug reporting.
18:07:51 <ashledombos[m]> i agree, but do i have voice? (as i'm only a infra maintener)
18:08:01 <bero> ashledombos[m]: sure you do
18:08:01 <rugyada> ben79:  agreeable
18:08:04 <ben79> This should be agreeable? Proposal: OM Bugzilla will continure to be used for ALL bug reporting and issue tracking.
18:08:06 <bero> ben79: +1
18:08:44 <itchka> +1
18:08:57 <crazy> +1
18:09:19 <ashledombos[m]> for this I abstain
18:09:19 <ben79> And maybe this: #Share We will explore using OM Bugzilla for Kanban or similar board for "To Do" and other lists and for tracking progress of "To Do" and other lists.
18:09:20 <itchka> So is that a share?
18:09:32 <itchka> #chair ben79
18:09:32 <chwido> Current chairs: ben79 itchka
18:09:41 <itchka> #chair bero
18:09:41 <chwido> Current chairs: ben79 bero itchka
18:09:46 <ben79> #Action TC-Meetings will remain the Official place for decision making for OM the distro. Discussion of issues to take place both in TC-Meetings and on Cooker ML but decisions are not Official until so stated in TC-Meeting.
18:09:48 <itchka> I have to go soon.
18:10:07 <ben79> If anyone disagrees speak up and we can discuss or revert any action or share I make.
18:10:16 <crazy> I don't
18:10:21 <crazy> :-)
18:10:31 <ben79> #Action OM Bugzilla will continure to be used for ALL bug reporting and issue tracking.
18:10:46 <ashledombos[m]> I'm just not sure we should not have an open door to change from bz at one time
18:11:19 <ben79> #Share We will explore using OM Bugzilla for Kanban or similar board for "To Do" and other lists and for tracking progress of "To Do" and other lists.
18:11:20 <ashledombos[m]> but not now clearly
18:11:44 <crazy> ashledombos[m]: well 'OM Bugzilla' as 'our bug tracking system/solution'
18:12:10 <crazy> ashledombos[m]: eg: not all over the place
18:12:17 <ben79> We can discuss changing from Bugzilla but so far no one has come up with anything substantive in that regard other than Github and Github is out.
18:12:41 <ashledombos[m]> Crazy in fact that's what i meant
18:12:58 <ben79> #Share Github will not be used for reporting bugs, issue tracking, or any kind of Official lists.
18:13:00 <crazy> ashledombos[m]: if , at some poit we want to change the issue tracker to be whatever else that is a different vote :-) bt will be still the OM Bugzilla :-)
18:13:14 <ashledombos[m]> ben79 i thought about using tichet tracking in gitea or whatever we use as github alternative
18:13:22 <crazy> ashledombos[m]: oh.. ok sry I am somewhat slow
18:13:56 <ashledombos[m]> crazy no sorry, i'm certainly slower 😁
18:14:47 <ben79> ashledonbos[m]: Nothing has been discussed at length other than switching to Github, and Github is out.
18:14:58 <rugyada> ok, but we have to state decision on current situation, not maybe-tomorrow situation ;-)
18:15:11 <rugyada> and for now it's that
18:15:16 <ashledombos[m]> To be clear, github is a no and until a better option bz is the best option
18:15:28 <ben79> Also if we are making a change form Github to self hosting git then we should not be changing from Bugzilla at the same time IMO.
18:15:33 <ashledombos[m]> yes, i agree
18:15:34 <rugyada> according to meeting agreement, ofc.
18:15:45 <ashledombos[m]> ben79 i agree too
18:15:56 <ashledombos[m]> I just wanted to keep an open door for later
18:16:18 <rugyada> ashledombos[m]:  sure, we has.
18:16:49 <ashledombos[m]> Then all is fine for me
18:16:56 <ben79> For the record I clearly see why people think there "must" be something better than bugzilla, but now is probably not the time for OM to do this.
18:16:59 <rugyada> if anything will show up reliable and doable we can discuss again, and again agree.
18:17:06 <crazy> ben79: in fact there is just one bugtracking system I know have all this stuff included and even an chat / forum addon for each project .. but is crazy to setup
18:17:16 <crazy> ben79: ashledombos[m] https://www.redmine.org/
18:17:52 <crazy> this has everything you need but really crazy to set up
18:17:54 <crazy> :D
18:18:23 <ashledombos[m]> I remember i used it in the past
18:18:50 <crazy> ashledombos[m]: some project I worked for got it up.. is really not bad .. I liked it
18:19:25 <crazy> ashledombos[m]: wiki, forum,chat, milestones , todo and what not
18:19:49 <crazy> you can setup all these for any individual project,branch etc
18:19:50 <ben79> Now proposal: #Share We will continue to discuss some method of enforcing that people all use TC-Meeting for decisions and that written policy is followed. This written policy: https://wiki.openmandriva.org/en/Policies/Repository_Policies and any additional policy we agree upon in TC-Meeting and publish in OM wiki.
18:20:17 <crazy> +1
18:20:21 <rugyada> +1
18:21:40 <ben79> We should add a date like have an enforcement policy in place by August 14 TC-Meeting?
18:22:17 <ashledombos[m]> +1
18:22:23 <ben79> That's 2 weeks, plenty of time to discuss this.
18:22:25 <crazy> +1
18:22:48 <rugyada> +1
18:22:58 <ben79> #Share We will continue to discuss some method of enforcing that people all use TC-Meeting for decisions and that written policy is followed. This written policy: https://wiki.openmandriva.org/en/Policies/Repository_Policies and any additional policy we agree upon in TC-Meeting and publish in OM wiki.
18:23:52 <ben79> # Share We will finalize and put in place by TC-Meeting of August 14, if not sooner, this enforcement policy.
18:23:59 <ben79> AS always don'
18:25:12 <ben79> AS always don't hesitate to disagree with any #Action or #Share I post if needed. (I hate meetings that drag on without ever deciding or doing anything. I prefer the "Do it and modify later if needed" approach.)
18:25:43 <rugyada> ben79:  I agree
18:28:27 <rugyada> looks like we covered the 2 items in agenda together
18:28:31 <ben79> For me this: #topic Working as a group is adequately covered for now, with enforcement mechanism to come as #Shared
18:29:38 <ben79> #Topic 2. Getting off github
18:31:13 * ben79 And I would propose that main topic for next TC-Meeting Aug. 7, should be maintenance/management of 4.0 and Rolling.
18:32:05 <ben79> We kind of have discussed getting off github and there seems general agreement to do it, so the questions are when? and how?
18:32:22 <rugyada> asap
18:32:35 * ben79 away for nature break
18:37:44 <rugyada> maintenance/management of 4.0 and Rolling
18:38:00 <rugyada> and maybe also definition of 4.0 and what to expect, because if all upgrades go to both rock and rolling then it does not look (just to me?) very clear the difference
18:46:57 <ben79> All upgrades are not going to 4.0. I just did a fresh install in last week and there were less than 30 packages total to upgrade. For Rolling the number will be in the 100's.
18:47:21 <bero> yes -- I don't think the whole KDE stuff should go to 4.0
18:47:30 <bero> and we should throw some more stuff from cooker at Rolling
18:47:37 <bero> need to get a bit more active there
18:47:59 <ben79> I think if it is time to upgrade the desktop it is time for a new release, normally
18:48:49 <bero> yes, aside from minor desktop updates
18:49:01 <bero> (e.g. I don't think we should make a new release for 5.16.3 -> 5.16.4)
18:49:16 <ben79> For both 4.0 and Rolling we need to get more people voting in Kahinah. So far I have moved packages myself because if I wait for 3 votes nothing would ever move.
18:50:00 <bero> IMO we should release 4.1 as soon as kapps 19.08 is in -- need to get out of "release never"
18:50:19 <rugyada> wow
18:50:58 <ben79> bero: yes, makes sense, so from 5.15.5 to 5.16.3 is legit for new release
18:51:17 <ben79> bero: then we'll need a working ISO builder!
18:51:59 <bero> true -- I'm currently fixing the dependency issues that broke my local iso build
18:52:06 <bero> btw 5.16.4 is ready
18:53:02 <rugyada> I'd like that all the already known 4.0 release bugs are fixed before 4.1
18:53:10 <ben79> I know itchka has some things he wants to bring up about 4.0 and rolling
18:54:15 <ben79> for me the main thing is that packages originally go to testing repos for both and QA at least has the opportunity to test things and then move them to rolling/release or 4.0/updates or 4.1/updates soon
18:55:05 <ben79> That has mostly been followed as far as I can see except for the occasional mistake, mostly in rolling.
18:55:39 * Pharaoh_Atem waves
18:55:42 <rugyada> can we close the meeting
18:55:44 <rugyada> ?
18:55:54 * ben79 waves back
18:55:59 <bero> One more thing: When do we announce rolling?
18:56:47 <ben79> I suppose when there are no package downgrades from 4.0 or 4.1 and there aren't many anymore, I'll need to check that actually.
18:57:16 <ben79> The main thing is we need more people to get involved and vote for packages in Kahinah
18:57:53 <ben79> And to keep track and be sure Kahinah is working correctly, what Kahinah is asked to do now has grown quite a bit
18:59:09 <rugyada> ‎[20:31] ‎* ‎ben79‎‎ And I would propose that main topic for next TC-Meeting Aug. 7, should be maintenance/management of 4.0 and Rolling.
18:59:18 <rugyada> bero ^^^ ok?
18:59:41 <bero> yes, works for me...
18:59:45 <rugyada> ty
19:00:15 <ben79> OK, github = git out
19:04:56 <rugyada> wrote main topic in Event and meetings calendar at forum so won't be forgotten
19:08:09 <ben79> Are we in position to decide anymore today about github other than we want to get free of it?
19:10:34 <rugyada> ben79:  anything else?
19:11:19 <ben79> Not for me. I'm just happy we got some #Actions and #Shares on the #1 Topic.
19:11:59 <rugyada> we have actions or shares for gh item already?
19:13:21 <ben79> As far as bugs there are some in https://issues.openmandriva.org/ mostly recently have been a lot of package bugs. The kind AngryPenguin does such an excellent job of responding to. Thanks for that AngryPenguin.
19:13:31 <rugyada> we discussed altogether so I may have missed some lines
19:14:35 <ben79> <ben79> #Share Github will not be used for reporting bugs, issue tracking, or any kind of Official lists.
19:15:09 <ben79> We have not done anything about leaving or mirroring github that I recall.
19:15:26 <rugyada> ok
19:15:48 <rugyada> so in short: # agreed github is unacceptable  # action move to self hosted or alternative :)
19:16:12 <ben79> Like maybe #Share OM will leave or otherwise free ourselves from dependence on github as soon as we feasibly can do so?
19:16:24 <ben79> Or #Action the above
19:17:17 <bero> ben79: probably better to #action it, if we #share it too widely before we're ready, someone at GH may get stupid ideas
19:17:29 <rugyada> lol
19:17:57 <rugyada> (but agree)
19:18:02 <ben79> #Action OM will leave or otherwise free ourselves from dependence on github as soon as we feasibly can do so?
19:18:22 <bero> sounds good to me
19:18:26 <ben79> I'm reasonably certain the above has already been agreed to.
19:20:26 <rugyada> OM will look for alternative to gh and move as soon as...
19:20:59 <ben79> Proposal: Let's post the #Actions and #Shares of this meeting and links to logs on Cooker ML .
19:21:27 <ben79> Proposal: In the hopes that everyone that needs to see this will see this.
19:22:02 <rugyada> ben79:  yes we can send reply to meeting call
19:22:45 <bero> right
19:24:40 <rugyada> if we endmeeting I can pick the lines and c/p them
19:24:47 <rugyada> from log
19:25:01 <ben79> OK,
19:25:13 <ben79> #Topic Any Other Business
19:26:36 <rugyada> AOB fwiw I'd like to get discover working
19:28:35 <rugyada> https://issues.openmandriva.org/show_bug.cgi?id=2503
19:29:20 <ben79> For Discover I think I agree in that it should either work or be gone one or  the other.
19:30:27 <ben79> But for some reason packagekit backend is not installed as a requires for discover right now, and I don't know if packagekit itself is fully up to speed functionally.
19:30:34 <rugyada> newcomers would expect discover working (sadly)
19:31:30 <rugyada> ofc it's not my own need
19:31:56 <rugyada> never used discover in OM
19:32:31 <rugyada> and also in *buntish distro I prefer other package manager gui
19:32:50 <AngryPenguin> discover...
19:32:57 <AngryPenguin> dnf remove discover
19:32:59 <AngryPenguin> = fixed
19:33:00 <AngryPenguin> :)
19:33:19 <rugyada> AngryPenguin:  sure, that's the trick :P
19:33:29 <rugyada> but... you know
19:33:39 <rugyada> ppl look for discover
19:34:19 <rugyada> and btw it's not even installed by default
19:34:24 <AngryPenguin> at some point we should try fix it
19:34:34 <AngryPenguin> even if it is not installed by default
19:34:55 <rugyada> ‎[21:32] ‎<‎AngryPenguin‎>‎ dnf remove discover
19:34:59 <rugyada> ^^^ :)
19:35:21 <rugyada> my reply was for this
19:35:42 <AngryPenguin> that solution for all users who already install it xD
19:35:52 <rugyada> lol
19:36:30 <Pharaoh_Atem> fixing discover shouldn't be that hard
19:36:59 <AngryPenguin> im not a fan of gnome stack, but from what I see, current gnome-software working better than discover
19:37:00 <AngryPenguin> :)
19:37:01 <Pharaoh_Atem> it worked when I first did the work on PackageKit...
19:37:01 <bero> unfortunately a lot of people seem to prefer "dnf remove openmandriva" for whatever reason
19:37:10 <bero> still less than 50 users worldwide :/
19:37:11 <rugyada> Pharaoh_Atem:  I'm willing to test any your try to fix it
19:37:25 <bero> that needs fixing at some point ;)
19:37:38 <Pharaoh_Atem> rugyada: I'll take a look when I get a moment
19:37:50 <Pharaoh_Atem> I have a vague idea of why it's all broken
19:38:01 <rugyada> Pharaoh_Atem:  sure just let us know when time will come
19:39:45 <rugyada> I will be more than happy to test it, find it working.. and soon after dnf remove discover :)
19:39:51 <Pharaoh_Atem> hah
19:40:06 <Pharaoh_Atem> rugyada: do we have a specific BZ of issues people are reporting?
19:40:14 <ben79> As I recall on default installion we have Discover but not discover-backend-packagekit. Discover won't work without that.
19:40:24 <rugyada> Pharaoh_Atem:  https://issues.openmandriva.org/show_bug.cgi?id=2503
19:40:29 <rugyada> started there
19:40:35 <bero> There's a few broken things in packagekit...
19:40:47 <bero> e.g. there's a hardcoded valid_arch[] list that doesn't include znver1
19:40:50 <Pharaoh_Atem> yeah, I'm pretty sure we need to do some fixing there
19:41:04 <bero> and there's valid_sourcesect[] which includes -contrib but not -unsupported
19:41:19 <bero> but that shouldn't affect people just trying to install x86_64 main packages
19:41:20 <Pharaoh_Atem> bero: are we at a place where you'd be comfortable with upstreaming znver1 to rpm, libsolv, libdnf, etc.?
19:42:19 <bero> Pharaoh_Atem: sure, works perfectly -- but I'm not sure the upstream projects will accept it, given a lot of people there insist we're doing it all wrong and should be building everything into one binary and using runtime feature detection
19:42:35 <Pharaoh_Atem> it's an architecture that exists, and we're doing it...
19:42:47 <Pharaoh_Atem> pentium4 and opteron exist, why not this?
19:43:19 <bero> I think it should exist -- just guessing from previous experience that upstream projects will say it shouldn't be done
19:43:38 <Pharaoh_Atem> well, it doesn't hurt to try
19:43:47 <Pharaoh_Atem> and you have me as an advocate
19:47:16 <bero> I just fixed some obviously wrong things in packagekit, but I doubt that will fix the entire thing
19:48:39 <Pharaoh_Atem> there's probably some patches we should sync from Fedora too
19:50:49 <bero> True, this looks useful
19:50:51 <bero> https://src.fedoraproject.org/rpms/PackageKit/blob/master/f/0001-dnf-Invalidate-the-sack-cache-after-downloading-new-.patch
19:51:51 <Pharaoh_Atem> I usually keep PackageKit packaging in Mageia and Fedora synced
19:51:56 <bero> possibly this too, I don't fully understand what the difference between system upgrade and regular upgrade is supposed to be... https://src.fedoraproject.org/rpms/PackageKit/blob/master/f/0001-dnf-Don-t-override-DnfContext-s-release_ver-for-the-.patch
19:51:58 <Pharaoh_Atem> and it's probably a good idea to do the same for OpenMandriva
19:52:14 <Pharaoh_Atem> bero: that's if we wire up the system-upgrade feature in discover and gnome-software
19:53:15 <Pharaoh_Atem> for upgrading from omv 4.0 to omv 5.0, for example
19:53:42 <bero> Well, "dnf distro-sync" -- what else can it do?
19:54:16 <Pharaoh_Atem> it is the equivalent of that
19:54:21 <Pharaoh_Atem> system-upgrade triggers distro-sync
19:54:35 <Pharaoh_Atem> verses regular update sequence
19:54:48 <Pharaoh_Atem> but system-upgrade also does it by rebooting into minimal systemd target to run the upgrade
19:55:10 <bero> We don't have that target (at least not for the moment)
19:55:18 <bero> so chances are any reference to it will break things
19:55:35 <bero> Same for this patch https://src.fedoraproject.org/rpms/PackageKit/blob/master/f/0001-offline-update-Use-new-plymouth-system-upgrade-and-r.patch
19:55:45 <bero> but the others make sense, certainly pulling the other ones in...
19:56:06 <Pharaoh_Atem> pulling them in certainly won't hurt anything
19:56:13 <Pharaoh_Atem> it's not going to make it _worse_
19:57:59 <bero> new pk building...
19:58:03 <bero> let's see if it's any good
19:58:13 <bero> 1.1.12-3 is the one to test
20:09:18 <ben79> Unless there's anything else I'm going to end meeting in 5 minutes
20:15:21 <ben79> #endmeeting dad gum it