14:04:11 <spotz> #startmeeting RDO meeting - 2020-11-18
14:04:12 <openstack> Meeting started Wed Nov 18 14:04:11 2020 UTC and is due to finish in 60 minutes.  The chair is spotz. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:15 <openstack> The meeting name has been set to 'rdo_meeting___2020_11_18'
14:04:20 <spotz> #topic Roll Call
14:04:32 <amoralej> o/
14:05:04 <jpena> o/
14:05:06 <fbo> o/
14:05:17 <spotz> Feel free to join us roman_g:)
14:05:26 <roman_g> o/
14:05:41 <spotz> #chair amoralej jpena fbo roman_g
14:05:42 <openstack> Current chairs: amoralej fbo jpena roman_g spotz
14:06:22 <spotz> jcapitao ykarel - meeting ping:)
14:06:39 <ykarel> o.
14:06:54 <spotz> #chair ykarel
14:06:55 <openstack> Current chairs: amoralej fbo jpena roman_g spotz ykarel
14:07:43 <spotz> $topic  Followup on Activate Fedora Zuul CI for distgit owned by openstack-sig
14:07:50 <spotz> fbo: the floor is yours
14:08:06 <fbo> spotz: thanks
14:08:08 <amoralej> spotz, you used $ instead of #
14:08:27 <spotz> bah!
14:08:30 <amoralej> topic will not be stored by meetbot i think
14:08:32 <amoralej> :)
14:08:34 <spotz> #topic  Followup on Activate Fedora Zuul CI for distgit owned by openstack-sig
14:08:53 <spotz> <-typo queen
14:08:53 <fbo> proposal is to add Fedora Zuul CI on all distgits owned by the openstack-sig group
14:09:20 <fbo> and then benefit defaults CI jobs on PR opened/updated on those distgit
14:09:37 <fbo> see https://src.fedoraproject.org/rpms/selinux-policy/pull-request/128#comment-60685 as an example
14:10:13 <spotz> @link https://src.fedoraproject.org/rpms/selinux-policy/pull-request/128#comment-60685
14:10:16 <spotz> argh!
14:10:20 <spotz> #link https://src.fedoraproject.org/rpms/selinux-policy/pull-request/128#comment-60685
14:10:31 <fbo> projects are listed here https://src.fedoraproject.org/api/0/group/openstack-sig?projects=1
14:10:48 <spotz> #link  https://src.fedoraproject.org/api/0/group/openstack-sig?projects=1
14:11:15 <spotz> Thoughts? COncerns?
14:11:59 <amoralej> i'm fine with it fbo
14:12:10 <fbo> It is not going to be complicated to setup as we already provide that CI for ~180 distgits and we have compute power to run far more CI jobs.
14:12:11 <amoralej> just note that we will be cleaning some fedora packages
14:12:12 <amoralej> https://review.rdoproject.org/etherpad/p/fedora_cleanup
14:12:22 <jcapitao> o/
14:12:29 <jpena> I'm fine with it. When discussed last week, it was pointed out that most of the time we don't do PRs for packages in Fedora, but this could be a good excuse to start doing it
14:12:42 <fbo> just a matter of adding the distgit list in https://pagure.io/fedora-project-config/blob/master/f/resources/fedora-distgits.yaml
14:12:53 <amoralej> i'm fine to use PRs but we need some CLI support
14:13:10 <amoralej> which does not exist currently, afaik
14:13:12 <spotz> #chair jcapitao
14:13:13 <openstack> Current chairs: amoralej fbo jcapitao jpena roman_g spotz ykarel
14:13:36 <jpena> ouch, I thought we'd have CLI support
14:13:52 <spotz> I just saw the dreaded PR:(
14:14:14 <fbo> amoralej: maybe this can help https://github.com/Mergifyio/git-pull-request
14:14:29 <fbo> There is a support for Pagure
14:14:59 <ykarel> fbo, is it true that it's just that zuul reports fail/success but not block to merge the PR even if there is failure?
14:15:11 <ykarel> or is that configurable
14:15:57 <ykarel> like with gerrit reviews we can switch voting/non-voting for those jobs
14:16:17 <fbo> ykarel: Zuul only run check jobs by default. Result is just informative then admin/owner/committer users can merge PRs even if the CI is red.
14:17:30 <fbo> we have a post merge workflow that is optional that perform the koji build automatically, but again that's optional :)
14:18:01 <ykarel> fbo, okk so it's configurable, ^ would also be helpful for us
14:18:15 <ykarel> to get the builds automatically post merge
14:18:18 <fbo> also the direct push is still supported obviously.
14:18:45 <amoralej> yes
14:18:55 <fbo> I suggest to start with the default, only check jobs.
14:18:56 <amoralej> i like the automatic builds post-commit
14:19:04 <amoralej> yes, makes sense
14:19:18 <ykarel> +1
14:19:41 <amoralej> fbo i'll test the whole workflow of fork/commit/PR/ with git-pull-request
14:20:03 <spotz> Should we plan on readdressing after you test amoralej?
14:20:06 <amoralej> and i'll see how we can adapt our tooling
14:20:31 <amoralej> i think we can move on with adding CI even before we change tool
14:20:38 <spotz> Ok
14:20:42 <amoralej> as it doesn't affect direct merges
14:20:50 <amoralej> and from time to time we get PRs on those repos
14:21:35 <fbo> Ok so I'll propose a PR to  https://pagure.io/fedora-project-config/blob/master/f/resources/fedora-distgits.yaml  to add the whole list of distgit.
14:22:19 <amoralej> ok
14:22:21 <amoralej> lgtm
14:22:29 <fbo> I'll keep you updated when ready to merge
14:22:37 <amoralej> thanks
14:23:40 <spotz> If nothing else on this we'll move on
14:23:46 <spotz> #topic https://review.rdoproject.org/etherpad/p/fedora_cleanup
14:23:50 <spotz> amoralej: Was that you?
14:24:17 <amoralej> i didn't add it, but i can go with it
14:24:27 <ykarel> i added it
14:24:36 <ykarel> amoralej u can take it ahead
14:24:57 <amoralej> so, we created a list of packages than can be cleaned from fedora
14:25:02 <amoralej> https://review.rdoproject.org/etherpad/p/fedora_cleanup
14:25:07 <amoralej> lines 5-19
14:25:09 <spotz> ykarel: You forgot to put your name:)
14:25:21 <ykarel> yes right :)
14:25:22 <spotz> #link https://review.rdoproject.org/etherpad/p/fedora_cleanup
14:25:27 <amoralej> there are still some open to discuss
14:26:02 <amoralej> as python-epi
14:27:10 <amoralej> next step, i'll send a mail to fedora-devel announcing it and then i'll start the process to remove for the ones where openstack-sig has permissions
14:28:06 <amoralej> jpena, there is something preventing to move on with https://review.opendev.org/#/c/762312/ ?
14:28:34 <jpena> amoralej: just waiting for another core reviewer
14:28:38 <amoralej> ok
14:28:41 <jpena> I'll make sure we check it tomorrow
14:28:43 <rdogerrit> Merged rdo-jobs master: Add undercloud fs050 upgrades to master/v/u periodic  https://review.rdoproject.org/r/31120
14:29:20 <amoralej> for the packages that are not managed under openstack-sig i'll ask owners to do the retirement or grant permissions
14:30:09 <spotz> Are there any other packages we don't have permissions on? Maybe a follow up effort?
14:30:36 <amoralej> no, i think that's it
14:31:02 <spotz> Ok
14:31:09 <spotz> Anything else on this topic?
14:31:26 <amoralej> ykarel, am i missing something?
14:31:42 <ykarel> amoralej, all good
14:32:30 <spotz> #topic RDO Release process improvement
14:32:35 <spotz> jcapitao: You're up
14:32:53 <jcapitao> we are working on improving the RDO release process
14:33:04 <jcapitao> #link https://review.rdoproject.org/etherpad/p/release-process-improvment
14:33:14 <jcapitao> so this pad was created to gather ideas and consider options
14:33:46 <jcapitao> for instance to centralize some steps of the process, or drop static data, stuff like that
14:35:11 <jcapitao> there is always a room for improvment, so if you have ideas feel free to share it on this pad
14:35:47 <spotz> When you say static data do you mean packages that don't change, docs, or something else?
14:37:06 <amoralej> the idea is to simplify the list of tasks in https://trello.com/c/gfYmxwO2/742-victoria-release-preparation
14:37:15 <amoralej> as much as we can, by automating things
14:37:15 <jcapitao> i mean old release names still present in code
14:37:24 <amoralej> well, or adding missing stuff if needed
14:38:05 <spotz> Everything I'm seeing on that ether and on the links for the suggested changes get +1 from me. Just trying to see if I see any negatives
14:38:46 <spotz> I don't think lists and variables are necessairly a con of code readability:)
14:39:12 <ykarel> also if we can have can have SIG members permissions for build/push release rpms it will be good
14:40:06 <amoralej> ykarel, yep, that's also part of the improvements
14:40:54 <spotz> Except for time commitment upfront vs at release are there really any downsides?
14:41:02 <jcapitao> spotz: yeah i see your point :) i'd say there is more risk of losing readability
14:41:08 <amoralej> and maybe we can also improve the documentation part
14:41:17 <amoralej> i just realized https://www.rdoproject.org/rdo/release-cadence/ is outdated :)
14:42:35 <jcapitao> :o
14:43:31 <ykarel> amoralej, ack will add that in etherpad along with some others
14:43:32 <spotz> I really want to revamp the website, add a contributors guide, etc. I just wish it was on gerrit so I wouldn't muck up the PRs
14:44:20 <jcapitao> why can't we migrate it to gerrit ?
14:44:37 <jpena> there's nothing preventing us from using gerrit. I think it was kept in GitHub mainly to make it easy for people to open a PR
14:44:38 <jcapitao> s/migrate/host/
14:45:00 <jpena> that said, if we just want to have a CI to see the result of a change, we could also work on that
14:45:02 <spotz> Can we please migrate to gerrit?!!!!:)
14:45:52 <spotz> If we have everything using the same tools it makes it easier for onboarding new contributors too:)
14:45:53 <jcapitao> indeed Github is more inclusive
14:46:12 <amoralej> while i prefer gerrit, i think PRs are more widely used
14:46:43 <amoralej> and the "edit in github" link, a very nice way to attract new contributors
14:46:44 <spotz> I'll give you all that
14:47:18 <jcapitao> difficult choice
14:47:54 <jpena> spotz: what would be the driver to move to Gerrit? Getting zuul jobs to test, using "git review"?
14:48:51 <spotz> jpena: Single set of tools, git review and the fact it rebases so you don't have all the out of date forks.
14:50:11 <spotz> It's just odd for docs and events we have one set of procedures and the code we have another. It separates our contributors and makes it harder for them to say go from editing docs to submitting code
14:50:56 <jpena> hm
14:51:00 <spotz> With 'Edit on Github' I'm assuming we didn't mean that leterally but fork, brank, and then PR
14:51:16 <spotz> If we did then we need to doc that
14:51:33 <jpena> how many external contributors did we get via the "edit on github" button? Maybe we're sticking to some ideas to attract new contributors that aren't working
14:52:13 <amoralej> it may be the case, yes
14:52:27 <amoralej> i always liked that feature, but you are right
14:52:27 <spotz> Can we tell? I know we pulled the website for the contributors list this release. I'm listed as new but I've patched the website before
14:52:35 <amoralej> dunno how much it's used
14:53:32 <spotz> It's not a bad feature in that it would still take you to the repo
14:54:09 <spotz> We can put it on the agenda for not next week but the week after?
14:54:42 <jpena> ok for me, let's review it then
14:54:46 <jcapitao> +1
14:55:06 <spotz> #topic Next Weeks Chair
14:55:06 <amoralej> the automated update of the actual web page doesn't depend on PRs, right?
14:55:32 <spotz> amoralej: Not sure, roman_g's PR is still testing I know
14:55:32 <jpena> amoralej: no, it triggers once the git repo is updated
14:55:49 <spotz> NM just passed
14:56:16 <jcapitao> I can chair next week
14:56:48 <spotz> Thanks jcapitao
14:57:05 <spotz> I'll try to peek in but taking the day off to go get my Turkey:)
14:57:33 <spotz> We've kinda already been Open FLoor but I'll make it official for the last 3 minutes
14:57:38 <spotz> #topic Open FLoor
14:57:53 <ykarel> A quick, so we have couple of retired projects, but there distgit still have contents, i have proposed https://review.rdoproject.org/r/#/c/31130/ for congress
14:58:25 <ykarel> please have a look and suggest so we can do that for other retired projects
14:58:28 <jpena> we'll have to force-merge those, but +1 to that
14:59:04 <spotz> +1
14:59:09 <ykarel> yeap force merge needed
14:59:52 <amoralej> lgtm
15:00:02 <jcapitao> good to keep a README
15:00:04 <jcapitao> +1
15:00:15 <spotz> And we're at time. Thanks everyone for coming.
15:00:20 <spotz> #endmeeting