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