14:11:39 <dirk> #startmeeting RPM Packaging Meeting 14:11:40 <openstack> Meeting started Thu Jan 14 14:11:39 2016 UTC and is due to finish in 60 minutes. The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:11:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:11:43 <openstack> The meeting name has been set to 'rpm_packaging_meeting' 14:12:23 <dirk> #topic new contributor mivanov 14:12:31 <dirk> mivanov: welcome 14:13:02 <IgorYozhikov> ok, I want to clarify the situation we have with testing. As i saw before OBS was attached in test mode 14:13:36 <toabctl> #topic gating state, what is done and what is planned to do 14:14:10 <toabctl> I can give a short summary about the current testing 14:14:42 <IgorYozhikov> toabctl: will be great 14:14:53 <toabctl> I did a zuul setup (which is currently not public) and created a job to build a package (iirc SLE_12 only currently) whenever a changeset is updated/created 14:15:36 <toabctl> the jenkins job is here 14:15:38 <toabctl> #link https://github.com/SUSE-Cloud/automation/blob/master/scripts/jenkins/jobs-obs/openstack-gerrit-rpm-packaging.yaml 14:15:48 <number80> hello 14:15:54 <IgorYozhikov> Hi number80 14:16:16 <toabctl> so it's using the packages from #link https://build.opensuse.org/project/show/Cloud:OpenStack:Upstream 14:16:33 <toabctl> then updates the specs and waits for OBS to rebuild the packages. 14:16:34 <number80> mivanov: hi 14:16:34 <IgorYozhikov> toabctl: So you use your own zuul instance 4 now, not OS infra's one 14:17:09 <toabctl> IgorYozhikov: yes. we had hackweek at SUSE and I had some time to play with it and wanted to get something done in some days. 14:17:29 <toabctl> IgorYozhikov: so this is an external CI system 14:17:45 <toabctl> IgorYozhikov: but I'm fine with moving this to the official openstack ci 14:18:39 <dirk> the real reason for setting up our own zuul was just a learning excercise 14:18:44 <IgorYozhikov> toabctl: I thought about to do something similar...but it should be scalable 14:18:56 <IgorYozhikov> dirk: i c 14:19:05 <toabctl> dirk: yes 14:19:42 <IgorYozhikov> I want to try to add https://github.com/dburm/docker-builder as stand alone build machine 14:20:45 <IgorYozhikov> In my plans - prepare scripts for nodepool centos image 14:21:00 <number80> actually, you can use the mock utility to do that, it just need RPM repo metadata 14:21:04 <IgorYozhikov> For further usage under OS infra 14:21:25 <number80> (which are common accross all major RPM distro) 14:22:25 <IgorYozhikov> number80: I know, these scripts(docker-builder) made by our build-team engineer 14:23:05 <number80> np 14:23:35 <number80> I'm looking at it, out of curiosity :) 14:24:03 <dirk> toabctl: and it is integrated already for new PRs ? 14:24:28 <toabctl> dirk: should be, yes 14:24:52 <toabctl> dirk: there was a problem with the zuul VM some time ago. but I think it's running. 14:25:07 <IgorYozhikov> dirk, toabctl when do you plan to move to OS infra zuul? I just want to be prepared to those moment - ie create scripts for nodepool 14:25:09 <toabctl> dirk: "recheck" and "recheck-suse" should trigger a rebuild 14:26:04 <dirk> toabctl: great! 14:26:25 <dirk> toabctl: which repository/distro does it check? 14:26:57 <dirk> toabctl: and can you change the link to point directly to the CI job ? 14:26:57 <toabctl> dirk: it uses https://build.opensuse.org/project/show/Cloud:OpenStack:Upstream as base and checks for SLE_12 iirc 14:27:10 <toabctl> dirk: sure. it's all WIP 14:27:15 <dirk> toabctl: e.g. in https://review.openstack.org/#/c/239874/ the link for "SUSE CI" check goes to the main page 14:27:24 <toabctl> dirk: there are more things which need some love. 14:27:30 <toabctl> dirk: I know 14:27:45 <dirk> ok, any action item that you want to work on in the next week related to that? 14:28:10 <toabctl> tbh I think I have not much time to work on that during next week 14:28:29 <toabctl> and if I find some time I would concentrate on a) reviews and b) new specs. 14:28:34 <dirk> number80: are you interested in checking that out and re-using it for RH builds perhaps ? 14:29:32 <number80> dirk: docker-builder? I guess not, we moved delorean to use mock instead of docker to ensure consistency with build system 14:29:59 <dirk> number80: sorry, no I meant the CI check for rpm-packaging things that toabctl added for SLE12 builds 14:30:35 <number80> dirk: sorry, yes, that's something we'd like to reuse if possible 14:31:30 <dirk> great.. should we set aside some time to actively look at it? :) 14:31:31 <number80> I'll talk w/ derekh about it, he'd be interested in having that as a third-party gating upstream 14:33:56 <dirk> #action review OBS/SUSE CI integration for RHEL testing 14:34:12 <dirk> #topic further upload of templates and common time from uploading to merge 14:34:22 <dirk> IgorYozhikov? 14:35:11 <IgorYozhikov> yes, I want to clarify - may I proceed with list proposed by me 14:35:34 * dirk can't remember the list 14:35:40 <IgorYozhikov> I'm about projects list 14:35:53 <IgorYozhikov> Meeting November 26th 14:36:05 <IgorYozhikov> http://paste.openstack.org/show/480122/ 14:36:38 <dirk> looks good to me 14:37:02 <IgorYozhikov> As I remember, we had to fix template syntax & I want to proceed 14:37:06 <toabctl> lgtm 14:37:18 <toabctl> template syntax was fixed 14:37:26 <IgorYozhikov> One more clarification - we are still skipping py3 14:37:48 <IgorYozhikov> or not 14:38:14 <toabctl> currently we skip it. 14:38:32 <IgorYozhikov> toabctl: thanx 14:38:33 <number80> upstream, we choose to standardize w/ python 3.5 but it's far from being usable 14:38:46 <number80> (as default python3 interpreter) 14:39:45 <IgorYozhikov> number80: 3.5? just curios because I saw < py3.5 for some projects in requirements.txt 14:40:09 <IgorYozhikov> or it is as longterm 14:40:15 <dirk> IgorYozhikov: do you have time to send PRs for the list you proposed until next week? 14:40:44 <number80> IgorYozhikov: long-term, it was discussed w/ stable branches maintainers in cross-project sessions (Tokyo) + zigo 14:40:54 <IgorYozhikov> yes, mostly for oslo, not sure about templates for clients 14:41:50 <IgorYozhikov> number80: thanx 4 reminding :) 14:41:54 <toabctl> number80: IgorYozhikov : I think debian has now 3.5 as default in sid and that's why zigo want to have 3.5 for openstack 14:42:04 <toabctl> there was a mail on the openstack-dev list 14:42:36 <toabctl> anyway - imho we should concentrate on getting *something* to be usable. so currently I don't care about py3 14:42:45 <dirk> +1 14:42:47 <number80> toabctl: we'll likely have 3.5 or later as default in RHEL8, so we're ok 14:42:59 <number80> +2 14:43:15 <number80> (about making things usable first) 14:43:39 <number80> enterprise distros will maintain python2 for a while anyway 14:43:50 <number80> and none are planning to remove python2 14:44:10 <IgorYozhikov> got it 14:44:49 <IgorYozhikov> dirk: I add AI to myself in etherpad about uploading oslo templates from list 14:46:05 <dirk> #action IgorYozhikov uploading oslo templates from list 14:46:08 <dirk> IgorYozhikov: thanks! 14:46:09 <IgorYozhikov> another part of topic question - amount of time required from patch-set to merge 14:46:20 <dirk> IgorYozhikov: thats next topic :) 14:46:34 <dirk> #topic Pending Reviews review 14:47:28 <dirk> I was noticing that we have a couple of reviews pending for quite some time on a 2nd +2 14:47:47 <dirk> e.g https://review.openstack.org/#/c/254036/ 14:47:47 <IgorYozhikov> https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open ? 14:47:52 <dirk> which blocks another one 14:48:08 <dirk> e.g. https://review.openstack.org/#/c/260518/ 14:49:08 <dirk> what is the policy that we want to follow for merges going forward? 14:49:11 <dirk> two +2's ? 14:49:23 <dirk> one +2 each at least from RH and SUSE ? 14:49:25 <toabctl> maybe we should lower that to a single +2 14:49:55 <dirk> or one +2 plus jenkins +1 for those that are having serious gating tests (e.g. the spec file tests that toabctl implemented) ? 14:50:38 <IgorYozhikov> dirk: agree about core +2 and CI +1 like verified 14:50:58 <IgorYozhikov> or Workflow 14:51:41 <dirk> number80: any comment? 14:51:45 <dirk> jruzicka: ping 14:52:35 <number80> I'll take a look 14:53:08 <number80> but until we have gating w/ builds, I'd rather stick to old policy 14:53:23 <number80> if we had builds running, I wouldn't mind lowering to a single +2 14:53:55 <dirk> number80: just to understand properly, gating against RH ? 14:54:02 <dirk> RHEL7 14:55:50 <number80> likely more CentOS 14:56:12 <dirk> sure 14:56:17 <dirk> ok 14:57:05 <toabctl> so if we stay with the current policy - how can we improve the review speed? 14:57:25 <IgorYozhikov> toabctl: agree, same question 14:57:49 <IgorYozhikov> may be we could attach irc bot here? 14:57:52 <number80> toabctl: 1. add me or jruzicka as reviewer 2. having weekly reports w/ stats would help having more people 14:57:54 <number80> +2 14:58:28 <dirk> number80: jruzicka and you are on those :) 14:59:17 <number80> dirk: yeah, needs to figure out how to free myself more time :( 14:59:40 <number80> Alan being even more busy as I do 15:00:26 <toabctl> IgorYozhikov: I think there are irc messages when a new change is proposed/updated 15:01:05 <IgorYozhikov> toabctl: yep, just looked though the channel history 15:01:47 <toabctl> number80: we could also try something like "2x +2 needed" but without any feedback after one week, a single +2 is fine to trigger the workflow 15:02:34 <number80> toabctl: could work for me too 15:03:04 <IgorYozhikov> toabctl: let's try 15:03:10 <toabctl> tbh I don't think it's a good idea but we would make at least a bit progress. 15:03:21 <toabctl> dirk: your opinion? 15:03:46 <dirk> toabctl: well, maybe two weeks, since everyone can be off legitimately for a week, but yes 15:04:08 <toabctl> 2 weeks are fine, too 15:04:44 <dirk> +1 15:05:10 <dirk> ok, any last minute topics? :) 15:05:47 <toabctl> #agreed 2x +2 needed, after2 weeks without response, a single +2 is enough to trigger workflow 15:06:18 <number80> ack 15:06:22 <IgorYozhikov> :) 15:06:39 <dirk> #endmeeting