13:01:17 #startmeeting rpm_packaging 13:01:18 Meeting started Thu Jul 21 13:01:17 2016 UTC and is due to finish in 60 minutes. The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:21 The meeting name has been set to 'rpm_packaging' 13:01:28 #chair number80 toabctl 13:01:28 Current chairs: dirk number80 toabctl 13:01:43 hi folks 13:01:47 #topic roll call 13:03:21 in case anyone has a topic to bring up 13:03:24 please add it to 13:03:30 #link https://etherpad.openstack.org/p/openstack-rpm-packaging 13:05:38 please add your name in the etherpad sidebar too 13:05:58 or your name on specific agenda item you've added 13:06:39 #topic Specs with patches, support by CI. 13:07:08 so we started this topic last week and postponed 13:07:36 basically question was if we would allow patches to be added to the upstream packaging that fix e.g. build failures or other important things that are needed for packaging a release 13:07:47 I'm torn between two extremes on this 13:07:54 does anyone have a strong opinion? 13:07:57 A must have IMO. 13:08:06 I feel we should not forbid it strictly but it should be discouraged 13:08:07 hi 13:08:39 discourage but it's gonna be needed sooner or later. 13:08:46 if we add patches, then it must be workaround until we get issue fixed upstream 13:09:06 I already had 2 CR's which required patching 13:09:08 so what is the policy.. usptream review backports that at least did not get a -2 ? 13:09:32 and no ninja-merge 13:09:40 do we allow downstream patches ? 13:09:50 astsmtl, for the 2 requirements the workaround was tojust wait for the next release, iirc. right? 13:10:04 In one case - yes. 13:10:12 In other we had to disable one test. 13:10:15 toabctl: yeah, currently releases fly in frequenntly. this might stop at some point later in the cycle / in the stable phase 13:10:47 And sometimes you can't wait, because it's a dependency. 13:11:02 For many other packages. 13:11:04 downstream patches are a possibility but I like to have a proper workflow for patches 13:11:16 jruzicka has good insight on how to do that 13:11:26 so currently at least our external ci has no support for tracking patches 13:11:28 (likely managing them as git patches queue) 13:11:59 yes if have patches we should have a clear workflow 13:12:00 I'd be fine with adding them as separate files alongside of the *.spec.j2 in the rpm packaging tree 13:12:14 and reference them with PatchX: lines in the spec.j2 like usual 13:12:17 +1 13:12:36 oh well, that makes it hard to manage the patches which is good since we don't want patches 13:12:50 :D 13:12:55 dirk: I'd standardize around %autosetup -S git and enforce that patches are generated from git 13:13:15 anyway, let's start with that and if we end up with a need to manage some patches ourselves, then we can investigate having patches branches 13:13:19 or else, we'll have patches breaking very often 13:14:03 jruzicka: could be a very simple script that git clone repo, import existing patches and then you add your new patches and then re-export 13:14:31 tracking branches is not something we can do quickly at this stage 13:14:56 just in case we need to maintain patches, it makes sense to maintain them in git (as opposed to simple files) 13:15:07 but ack for accepting patches as files for now 13:15:10 number80: well, we don't have a git repo for that, do we ? 13:15:20 %autosetup works also for me 13:15:26 dirk: nope, but this is somethinge we can work out 13:15:37 (not a blocker) 13:16:05 Fedore discourages use of VCS in %autosetup: https://fedoraproject.org/wiki/Packaging:Guidelines#.25autosetup 13:16:11 #action number80 work on guidelines for patches management and send review 13:16:19 s/Fedore/Fedora 13:16:26 yup, +1 for cautiously accepting patches as files 13:16:59 astsmtl: that's a recommendation, not a guideline, I can name few core packages that relies on git 13:17:22 ok, so do we summarize on we allow patches? 13:17:28 *nods* 13:17:38 with or without autosetup? or do we postpone that ont he part when it happens? 13:17:42 Ok, I'm in no way affiliated with Fedora, so I'll trust you. :) 13:18:08 astsmtl: well, if it wasn't the case, I'd have this guideline changed :0 13:18:36 dirk: autosetup to enforce consistency 13:18:54 can you explain? 13:19:54 dirk: %autosetup -S git will fail if you don't use patches generated from git, and git generated patches are easy to rebase (in case, we ship downstream patches, that's useful) 13:20:14 I don't plan to have any downstream patches but I don't want to enforce that on other targets 13:20:50 ok 13:20:51 and one advantage for git generated patches: tracking their origin 13:21:30 we have a script to track technical debt and it can use commit message info to verify if a patch comes from openstack review or not (and votes) 13:22:07 yup, sounds good to me 13:22:51 (maybe we should just state that patches are ok and move to the next topic) 13:23:04 We can always discuss details during upcoming reviews 13:23:24 +1 13:23:41 * dirk tries to summarize 13:24:06 #agreed we allow patches but they're heavily discouraged 13:24:24 to be honest I lost the status around %autosetup 13:24:41 so we can use %autosetup iwthout git as well? I don't know how we would be doing autosetup with git in our repo 13:25:35 number80: what do we agree on for now? 13:26:58 I don't understand how we#d be doing a git rebase tree with our rpm-packaging repo 13:27:01 Let's say %autosetup -S git is encouraged, and move on. 13:28:18 #agreed if %autosetup is used, then %autosetup -S git is encouraged 13:28:41 #topic Logo Mascot status + submission (see https://etherpad.openstack.org/p/openstack-rpm-packaging-logo-ideas ) 13:29:20 well, consensus is we should have a box in the logo :) 13:29:35 indeed 13:29:42 not sure if thats an animal fish or plant though :) 13:29:56 dead trees! 13:30:19 Metal box! 13:32:21 lol 13:32:38 well, the deadline is July,27? 13:32:41 so groundhog or donkey in a box are candidates 13:33:13 basically before next meeting 13:33:35 do we want to do a formal vote? 13:33:37 so it't be nice to get rid of that today ;) 13:33:46 Deb people decided to do something like this: https://raphaelhertzog.com/files/2010/10/new-package-magic-300x228.jpg 13:33:47 can everyone add items and add +1s behind it? 13:34:13 would that work? 13:34:55 yup 13:35:16 Ahaha! 13:35:20 #action all review https://etherpad.openstack.org/p/openstack-rpm-packaging-logo-ideas and add +1s for each logo idea you like 13:35:48 astsmtl: add it as a logo idea then to etherpad 13:36:09 I will review the etherpad by early next week 13:36:26 so please submit votes by sunday evening 24th whatever timezone you're in 13:36:27 thanks 13:36:34 dunno, boxes and kittens kinda go together :D 13:36:38 dirk, I'm not sure if it's okay to use same idea. :/ 13:37:16 astsmtl: it should be unique, the logo is still fairly "minimal" to me though 13:37:36 astsmtl: did you mean the openstack deb packaging people or deb people in general? 13:37:51 OpenStack. 13:37:56 thanks 13:38:07 I'd still be fine with choosing a similar idea 13:38:16 or mascot with a small rpm / deb branding 13:38:28 at the end of the day we want to collaborate 13:39:43 ok to move on? 13:39:56 #topic packages reviews (https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open ) 13:40:19 I was going over the reviews an hour ago last time 13:40:24 things are progressing as far as I can see 13:40:35 main showstopper are various CI failures eveywhere 13:40:45 I have submitted a change for a new pymod2pkg release 13:40:59 #link https://review.openstack.org/#/c/345327/ 13:41:10 this should unblock some of the python-client*s from going in 13:41:39 any idea what else is missing? I have seen a couple of MOS CI failures on stable/mitaka reviews that are blocking things right now 13:41:45 e.g. we'd desparately need 13:41:59 #link https://review.openstack.org/#/c/342030/ 13:42:03 (sorry urgent call) 13:42:08 but gating fails on this for significant amount of time 13:42:13 (and needs rebase right now= 13:43:01 any review we want to discuss here? 13:43:30 #topic https://review.openstack.org/#/q/project:openstack/renderspec+status:open 13:43:48 #link https://review.openstack.org/#/c/336151/ 13:43:56 has a bit of debate in there, do we want to discuss this here? 13:43:59 I'd like your opinion on https://review.openstack.org/#/c/336151/ 13:44:03 yes please 13:44:38 jruzicka: I haven't read the review, can you summarize? 13:45:09 in short, it changes the default behavior from "use file if present" to "always require command line argument" 13:45:52 but it's a question about use case 13:46:21 My main argument is that current default is relative (just a file name), so it depends on cwd. 13:46:39 And I can't see better defaults here. 13:47:19 Oh yeah what you wrote makes sense 13:47:52 so it's moving, let's continue with this off meeting 13:48:03 ok 13:48:21 * dirk feels that a --yes-i-know-the-file-isnt-there might be a potential solution 13:48:30 #topic open floor 13:48:33 anything else to cover? 13:49:08 I'd just like to mention I'd like to improve renderspec 13:49:22 to cover differences we have better, lemme find the link 13:50:00 https://etherpad.openstack.org/p/renderspec_RFE 13:50:42 after some research, I'd like to use jinja {% blocks %} to allow distro-specific magics 13:51:19 espiecially, if you noticed some discrepancy between RDO and suse packaging that should be covered, please put it in the above document or just let me know 13:52:29 #link https://etherpad.openstack.org/p/renderspec_RFE 13:52:30 jruzicka: thanks 13:52:37 #action all review etherpad until next week 13:53:43 jruzicka: I'll take a look 13:53:48 * dirk has to run though in a min 13:53:50 anything else? 13:53:55 dirk, thanks in advance ;) 13:55:12 #endmeeting