13:01:19 <dirk> #startmeeting rpm_packaging
13:01:20 <openstack> Meeting started Thu Mar 17 13:01:19 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:23 <openstack> The meeting name has been set to 'rpm_packaging'
13:01:50 <toabctl> hi
13:02:01 <mivanov> hi
13:02:48 <dirk> please add your topics to https://etherpad.openstack.org/p/openstack-rpm-packaging
13:03:23 <toabctl> and please add your names (top right corner) to the etherpad
13:03:40 <toabctl> or at the end of the topic
13:06:24 <dirk> can we start?
13:06:32 <dirk> anything missing?
13:06:41 * IgorYozhikov bbs @ 5 min, start please
13:06:46 <dirk> #topic maintaining a global-requirements and remove all versions from specs? (toabctl)
13:08:09 <dirk> imho yes.. do we need to discuss it ? :)
13:08:23 <dirk> I guess you want to discuss how to do it - if we want to double check for differences ?
13:08:51 <toabctl> I wanted to know where to maintain the file. so should we just add it to the root of rpm-packaging git repo?
13:10:36 <toabctl> and also, should we just copy the file from requirements git repo in the beginning?
13:11:01 <number80> hello
13:11:47 <dirk> hey number80 , welcome
13:12:03 <dirk> toabctl: IMHO it should be in the root, yes
13:12:27 <toabctl> hey number80
13:12:37 <toabctl> ok. so agreed on it?
13:12:44 <dirk> toabctl: but whats the nameing? do we call it requirements.txt ?
13:12:50 <dirk> its not really runtime requirements overall I guess
13:13:13 <IgorYozhikov> dirk, GR in root like autosync results?
13:13:24 <toabctl> it can not be called requirements.txt . that would be missleading
13:13:28 <IgorYozhikov> GR - global-requirements
13:13:45 <dirk> toabctl: I think we need to find a new name that is not taken already by update scriptlet
13:13:49 <IgorYozhikov> just get back
13:13:59 <toabctl> maybe versions.txt
13:15:23 <IgorYozhikov> requirements for particular projects could have more information related to project than global-requirements
13:15:58 <toabctl> true
13:16:27 <IgorYozhikov> toabctl, am I right that we are discussing - how to use requirements feature withing CI/automation, right?
13:17:04 <toabctl> IgorYozhikov: we are discussing where we want to maintain for now a "global-requiremts" file and what name that file should have
13:17:07 <IgorYozhikov> because in manual mode - I just download requirements from github/project
13:18:56 <IgorYozhikov> sync requirements from projects repos to root of template folder - could solve this, but it should be made by some kind of CI job| bot
13:19:35 <toabctl> that doesn't help. some projects use setup.cfg to define requirements
13:19:49 <IgorYozhikov> toabctl, this is true
13:20:02 <toabctl> and all (setup.cfg, requirements.txt) are synced from the global-requirements.txt file
13:20:25 <toabctl> I explcitly asked in #openstack-olso about the setup.cfg a couple of days ago
13:21:04 <dirk> so canwe as a first start just copy global-requirements.txt under that name?
13:21:07 <toabctl> so my suggestion would be that we just sync a single file. downstream (suse, miratin, redhat, ...) can be more fingrained if needed with requirements
13:21:26 <dirk> if I understand the the current update.py job, you can somehow configure which files it syncs to
13:21:32 <dirk> so we'd need to list it in the project and be done with that
13:21:34 <toabctl> but I think that if adjustments are needed, it's usually an upstream bug
13:21:54 <toabctl> dirk: I think that's it. yes
13:22:23 <IgorYozhikov> dirk, toabctl - autosync via proposal bot, right?
13:22:32 <toabctl> I guess we need to add an initial file to our repo
13:22:36 <toabctl> IgorYozhikov: yes
13:22:40 <IgorYozhikov> cool
13:22:49 <toabctl> so again the questing - how should we call that file? :)
13:24:08 <dirk> my vote is global-requirements.txt if we can configure the proposal bot to use that name
13:24:17 <dirk> if I understand the code correctly (just looking at it) it is configurable
13:24:19 <IgorYozhikov> if it will synchronized - do we need a special name? just trying to understand - for what purpose rename is required
13:24:38 <toabctl> global-requirements.txt is fine for m
13:24:40 <toabctl> e
13:24:44 <number80> ack
13:24:48 <IgorYozhikov> +1
13:24:50 <toabctl> I'm just against the name requirements.txt
13:25:08 <IgorYozhikov> cool, let's leave it as GR
13:25:22 <IgorYozhikov> global-requirements.txt
13:25:26 <toabctl> who's taking the action to create the sync PR and the initial file (if needed)
13:25:32 <dirk> toabctl: and test-requirements I guess?
13:25:37 <dirk> it looks like it is not configurable
13:25:59 <toabctl> hm.yeah. test-requirements.txt , too
13:26:16 <IgorYozhikov> dirk, test-requirements - for further usage like for Build time reqs
13:26:18 <dirk> #agreed use global-requirements.txt for the copy of the global requirements
13:26:26 <toabctl> but there again I'm against that name. having a test-requirements.txt in root usually means that this file is used for testing (with pip)
13:26:33 <dirk> AI: add initial copy, implement proposal bot sync at a later point
13:26:41 <dirk> #action add initial copy, implement proposal bot sync at a later point
13:27:08 <dirk> toabctl: yeap. looks like we need to extend the usecase of the proposal bot syncing script and implement updating of the global-requirements.txt file
13:27:22 <dirk> shouldn't be difficult with CI integration, this is rather nice (we can fix stuff before things explode)
13:27:35 <toabctl> yeah
13:28:41 <dirk> next topic?
13:28:45 <IgorYozhikov> yep
13:28:53 <dirk> #topic Common spec formatting
13:29:28 <dirk> one thing I noticed while reviewing spec file templates recently is that we seem to have different indentation / tag ordering rules
13:29:28 <IgorYozhikov> indents key:               value?
13:30:02 <dirk> I was wondering if we can agree on a common order (SUSE has a policy checker for that, we could integrate it) or if we want to keep it free form
13:30:14 <IgorYozhikov> dirk, agree, let's figure out optimal indentation and I'll post it to wiki page
13:30:34 <dirk> e.g. we have a defined order between Name: Version: Epoch: BuildRequires and so on
13:30:37 <dirk> and indentation
13:30:42 <toabctl> a checker job would be better that wiki, imo
13:31:16 <dirk> yeah, its on my pet projects ..
13:31:25 <IgorYozhikov> toabctl, yes, also will be a big plus to run rpm lint after rendering stage
13:31:44 <dirk> IgorYozhikov: rpmlint is part of the SUSE CI job already..
13:31:57 <dirk> but we only fail the job on very distinct (bad) errors
13:32:01 <IgorYozhikov> dirk, great
13:32:25 <number80> yes, the same for me
13:32:28 <dirk> regarding the spec formatting
13:32:39 <dirk> compare https://build.opensuse.org/package/view_file/Cloud:OpenStack:Factory/python-keystoneclient/python-keystoneclient.spec?expand=1
13:32:42 <IgorYozhikov> so, sounds that spec.j2 linter required aka pep8
13:32:50 <dirk> with https://review.openstack.org/#/c/290472/5/openstack/python-keystoneclient/python-keystoneclient.spec.j2
13:33:11 <dirk> IgorYozhikov: yeah.. we have a thing called "spec-cleaner" that enforces a standard style
13:33:15 <IgorYozhikov> yes, I saw that
13:33:36 <dirk> we could easily check whether there is a diff and add a job that fails the jenkins check then (as part of the existing lint job)
13:33:55 <IgorYozhikov> dirk, where to "buy" this cleaner? :)
13:33:58 <dirk> but I'm not sure if the template formatting is something where people have strong opinions about it
13:34:09 <IgorYozhikov> or it is publicly available?
13:34:19 <dirk> IgorYozhikov: there are two implementations: spec-cleaner is here: https://github.com/openSUSE/spec-cleaner
13:35:12 <toabctl> oh. it's even python :)
13:35:18 <IgorYozhikov> dirk, thanx a lot. will look though
13:35:55 <dirk> and the 2nd one is here:  https://github.com/openSUSE/obs-service-format_spec_file
13:36:01 <dirk> one perl one python
13:36:11 <dirk> spec-cleaner is slightly better (newer)
13:36:25 <dirk> the other one is deprecated
13:36:26 <IgorYozhikov> as I know obs - is some kind of perl
13:36:57 <dirk> IgorYozhikov: not really. OBS is a plethora of implementation languages :)
13:37:21 <IgorYozhikov> I am about a lot of scripts, that are under the hood
13:37:39 <dirk> ok, so what did we agree on, having a common spec formatting ?
13:37:50 <dirk> so next step would be to write the checker job?
13:37:55 <toabctl> +1 common spec formatting
13:38:45 <IgorYozhikov> dirk, at first might be good to determine values for indentation, etc
13:38:46 <dirk> or next step is to come up with a common formatting ?
13:38:54 <IgorYozhikov> agree on formatting
13:39:12 <dirk> number80: any opinion?
13:39:34 <number80> +1 for common formaating
13:39:36 <IgorYozhikov> I could made 2 -3 variants of j2s for discussion
13:40:54 <IgorYozhikov> thought?
13:40:58 <dirk> works for me
13:41:11 <dirk> #agreed we should have unified spec template style (ordering, indentation)
13:41:21 <dirk> #action come up with proposals for unified spec style
13:41:31 <Cristina> Hi!
13:41:49 <toabctl> hi Cristina
13:42:06 <IgorYozhikov> dirk, so AI on me of for whom?
13:42:09 <IgorYozhikov> hi Cristina
13:42:29 <IgorYozhikov> s/of/or/
13:43:09 <dirk> hi Cristina
13:43:19 <dirk> IgorYozhikov: I guess for all.. but if noone else volunteers, its for you :)
13:43:49 <dirk> suse has a pretty rigid style so whatever we come up with its going to be reformatted to that style anyway
13:43:59 <IgorYozhikov> dirk, :)
13:44:06 <dirk> so it is one of the options.. since the code for that is already there
13:44:22 <dirk> but I'm not torn on this. if there is a different style that people agree to then lets use that
13:44:57 <dirk> #topic CI vote or not vote mode(when enable voting?)(IgorYozhikov)
13:45:12 <IgorYozhikov> So, I'll propose a couple of variants in etherpad
13:45:28 <IgorYozhikov> mine topic, about CI
13:45:29 <toabctl> which etherpad?
13:45:39 <IgorYozhikov> toabctl, new one
13:46:24 <IgorYozhikov> I'll update you on irc channel when finish with formatting variants
13:46:25 <dirk> IgorYozhikov: ok, want to create the etherpad and add a #link to the meeting minutes right now?
13:46:29 <dirk> or that..
13:47:11 <IgorYozhikov> I can do it right now, yes
13:47:47 <IgorYozhikov> #link https://etherpad.openstack.org/p/spec.j2.formatts
13:48:06 <IgorYozhikov> next topic - CI about mode?
13:48:14 <dirk> yep please
13:48:17 * dirk has a hard stop upcoming
13:48:28 <dirk> whats the topic about ?
13:49:07 <IgorYozhikov> dirk, I just want to clarify conditions to make CI voting
13:49:09 <number80> I suspect it's about fixing criteria to decide when to enable a voting gate
13:49:21 <IgorYozhikov> number80, yes
13:49:56 <toabctl> is it possible to make an external Ci voting?
13:50:47 <IgorYozhikov> I suggest to collect results aka statistics
13:51:07 <IgorYozhikov> for all attached | will be attached CIs
13:51:34 <number80> toabctl: we need to check with infra
13:51:38 <IgorYozhikov> I can clarify about voting from 3rd party CI
13:51:51 <number80> but they offered us to host builders
13:52:19 <dirk> IgorYozhikov: number80 : as far as I understand there is a wiki page from the infra team about this already
13:52:23 <dirk> I read it a few days ago
13:52:58 <dirk> basically summary is that by default all gates are non-voting, and in order to upgrade them to voting you need to send a mail to the dev list about proposing that (and seinding an infra change that ups it to voting)
13:53:09 <dirk> the infra team needs to white list gates
13:53:19 <number80> ack
13:53:38 <IgorYozhikov> fine
13:53:49 <IgorYozhikov> openstack-dev, why not
13:54:36 <toabctl> so should we try to make our current CI voting?
13:54:45 <IgorYozhikov> and if there is an opportunity to do this, we need just elaborate criteria
13:55:10 <IgorYozhikov> toabctl, I suggest to do this after summit
13:55:16 <dirk> toabctl: "our" you mean the "SUSE CI" labelled thing (that is really mislabelled right now)
13:56:03 <toabctl> IgorYozhikov: is there anything happening during summit? or why waiting?
13:56:12 <IgorYozhikov> because Mirantis is also working on CI, and I believe that it will be online in a couple of weeks
13:56:17 <toabctl> dirk: yes.
13:56:38 <toabctl> IgorYozhikov: that can be added as CI, too
13:56:52 <dirk> IgorYozhikov: so you want to add all CIs as voting in one go?
13:56:56 <IgorYozhikov> toabctl, ok
13:57:06 <IgorYozhikov> more | less on one go
13:57:15 <IgorYozhikov> at 1st - collect data
13:57:19 <IgorYozhikov> as results
13:57:43 <IgorYozhikov> about failed & succeeded runs
13:57:45 <toabctl> I would add new CIs as external for some weeks (for testing) and then eventually add them as voting
13:58:56 <IgorYozhikov> We are doing the same, long term - switch to rpm-packaging - 1st spec source
13:59:14 * dirk has to leave..
13:59:30 <toabctl> ok. I guess we need more discussion on that
13:59:40 <toabctl> maybe next week or in #openstack-rpm-packaging
13:59:49 <toabctl> dirk: can you close the meeting? time is over anyway...
14:00:04 <dirk> lets continue discussion in #openstack-rpm-packaging
14:00:06 <number80> seack
14:00:10 <dirk> #endmeeting