17:00:41 <kzaitsev_mb> #startmeeting murano
17:00:42 <openstack> Meeting started Tue Jan 26 17:00:41 2016 UTC and is due to finish in 60 minutes.  The chair is kzaitsev_mb. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:46 <openstack> The meeting name has been set to 'murano'
17:01:11 <kzaitsev_mb> #topic rollcall
17:01:16 <stan_lagun> o/
17:01:17 <zhurong> o/
17:01:20 <freerunner> \o/
17:01:22 <ativelkov> o/
17:01:23 <Nikolay_St_web> o/
17:01:26 <kzaitsev_mb> Serg asked me to chair the meeting today
17:01:33 <kzaitsev_mb> so here we are )
17:02:24 <kzaitsev_mb> obligatory
17:02:26 <kzaitsev_mb> o/
17:02:26 <madhuri> o/
17:04:11 <kzaitsev_mb> agenda for todays meeting can be found here https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:04:30 <kzaitsev_mb> as usual let's start with AI review from prev meeting
17:04:53 <kzaitsev_mb> (also agenda had an item added by madhuri, but it was a leftover from prev meeting =))
17:04:59 <kzaitsev_mb> #topic Action Items Review
17:05:20 <kzaitsev_mb> k, so we had an item for serg about murano-apps release model
17:06:02 <kzaitsev_mb> as far as I know he hadn't time to tend it, and since M2 already happened — there is no rush anymore
17:06:25 <kzaitsev_mb> release models are frozen until Mitaka release (there was an email from Thierry I think)
17:06:43 <kzaitsev_mb> So I think we can omit it from agenda for the next meeting
17:06:57 <kzaitsev_mb> 2) ativelkov — I hate to remind you =)
17:07:15 <ativelkov> plugins? )
17:07:24 <kzaitsev_mb> yep (=
17:07:33 <ativelkov> Sorry, still no progress here
17:07:37 <kzaitsev_mb> does anyone remember why we wanted it in the first place?
17:07:44 <kzaitsev_mb> seems like it's a no rush thing too )
17:09:15 <kzaitsev_mb> ah I remember — we had concerns about packaging our murano client with plugin and separate setup.cfg's
17:09:26 <kzaitsev_mb> I suggest we cancel the item altogether =)
17:10:28 <kzaitsev_mb> and instead let's ask around some packaging folks about how it should be done. zigo and/or iyozhikov and/or someone else, who's proficient with packages
17:11:56 <kzaitsev_mb> #action kzaitsev_mb ask around packaging folks — how we should handle murano-glare plugin and murano-specific plugins packaging-wise
17:12:11 <kzaitsev_mb> ok.
17:12:24 <kzaitsev_mb> #topic Juno branch retirement(Request by AJaeger)(freerunner)
17:12:32 <kzaitsev_mb> freerunner: any comments? =)
17:12:39 <freerunner> Here I am =)
17:14:10 <freerunner> kzaitsev_mb: I'm working on patch https://review.openstack.org/#/c/270770/ . So, when AJaeger gives me +2, he also post a comment about Juno branches.
17:14:45 <freerunner> kzaitsev_mb: he said, that Juno EOL (yep, we knows it), but also, we should remove Juno branch from our github repo.
17:14:55 <kzaitsev_mb> so as far as I understand — we're politely requested, that we should remove Juno =)
17:15:01 <kzaitsev_mb> #link https://review.openstack.org/#/c/270770/
17:15:06 <freerunner> kzaitsev_mb: Exactly =)
17:15:18 <kzaitsev_mb> To tell the truth — I thought infra folks handle those =)
17:15:29 <kzaitsev_mb> we had EOL for juno tagged and released on time
17:15:45 <kzaitsev_mb> so are there any objections to dropping Juno branch?
17:16:11 <kzaitsev_mb> (I've actually pinged Serg about it — he had none)
17:16:37 <freerunner> kzaitsev_mb: I've also saw, that we have a lot of first-time branches in openstack/murano repo, like 0.1, 0.2 etc.
17:17:33 <kzaitsev_mb> freerunner: true
17:17:45 <freerunner> kzaitsev_mb: Maybe we can perform a totally cleanUp for our repo?
17:17:50 <kzaitsev_mb> wonder if they're used by anyone =)
17:19:53 <kzaitsev_mb> freerunner: those branches actually contains some commits, that are not reachable through master
17:20:04 <kzaitsev_mb> wonder if we need them... for history resons? =)
17:22:15 <freerunner> kzaitsev_mb: maybe..
17:22:26 <kzaitsev_mb> ok, so I think that I am the one who has the rights to delete branches
17:22:29 <kzaitsev_mb> so
17:22:30 <zhurong> kzaitsev_mb I think we should have the tags, do not need maintain the branch
17:22:44 <kzaitsev_mb> #atcion kzaitsev_mb delete stable/juno branches
17:22:50 <kzaitsev_mb> zhurong: yep, we should
17:23:09 <kzaitsev_mb> but those brnahces contain commits, that are not reachable through master
17:23:26 <kzaitsev_mb> so if we would simply drop them — we would delete some of the history irrevocably
17:23:28 <stan_lagun> will it disappear from github?
17:23:43 <kzaitsev_mb> stan_lagun: they will, yes
17:23:50 <stan_lagun> that's bad
17:24:08 <stan_lagun> but may be a tag will be okay
17:24:26 <Nikolay_St_web> stan_lagun: tags are fine for most cases
17:24:43 <stan_lagun> I often compare class changes in github by switching view from branch to branch. And many people still use juno
17:24:51 <kzaitsev_mb> stan_lagun: tags won't help here, since we would drop a branch, that contains the tag.
17:25:06 <stan_lagun> but I guess I can do the same using tag. Just more clicks needed
17:25:18 <kzaitsev_mb> at least that's how I believe git works +)
17:25:24 <Nikolay_St_web> kzaitsev_mb: don't we have all our tags in master branch?
17:25:52 <kzaitsev_mb> Nikolay_St_web: we're actually talking about legacy tags here
17:26:00 <kzaitsev_mb> or are you talking about juno?
17:26:23 <Nikolay_St_web> kzaitsev_mb: I guess stan_lagun asked about juno
17:26:33 <Nikolay_St_web> and I tried to be on the same page :)
17:26:33 <stan_lagun> can't we just exclude it from all tests etc but leave the branch?
17:27:16 <stan_lagun> it is still important to be able to see what methods did some class had in juno
17:27:32 <freerunner> stan_lagun: Not sure. I think, that we can ask Andreas about it.
17:27:43 <Nikolay_St_web> stan_lagun: tags are helphul here
17:28:02 <freerunner> stan_lagun: We also can ask infra-guys in the mailing list.
17:28:05 <kzaitsev_mb> #undo
17:28:06 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x9644650>
17:28:58 <kzaitsev_mb> #action kzaitsev_mb verify that all tags are present in master, and check how we would be able to access juno code before deleting juno branch
17:29:03 <zigo> kaisers1: What concern did you have?
17:29:48 <kzaitsev_mb> zigo: it was I =) sorry, for pinging you like that =) would reach out to you after the meeting is over, would that be ok?
17:30:15 <zigo> kzaitsev_mb: Yeah.
17:30:48 <kzaitsev_mb> #action freerunner with kzaitsev_mb ask infra and stable-maint folks how we should delete and access juno branch content after juno branch deletion
17:31:20 <kzaitsev_mb> stan_lagun: so yep, I believe we should have tags in place to do what you asked
17:31:28 <freerunner> kzaitsev_mb: Sahara now have only kilo, liberty and master branches. But tags like 2014.1, 2014.2 available in git. https://github.com/openstack/sahara/tree/2014.2
17:31:33 <kzaitsev_mb> but I believe, we would be required to have the branch removed
17:32:33 <kzaitsev_mb> freerunner: yep, but
17:32:36 <kzaitsev_mb> $ git branch --contains 2014.2.2
17:32:43 <kzaitsev_mb> gives me stable/juno for murano
17:34:00 <kzaitsev_mb> ok, I might be mixing things up
17:34:19 <kzaitsev_mb> anyway, those 2 action items sound like a plan to me
17:34:33 <freerunner> kzaitsev_mb: Agreed, yep.
17:35:22 <kzaitsev_mb> stan_lagun: we'll make sure, that there will be an easy way to access juno murano after deleting the branch. And only after we're sure, that it's there we'll delete it.
17:35:38 <stan_lagun> kzaitsev_mb: thanks!
17:35:55 <kzaitsev_mb> that was the only item on agenda, so.
17:36:03 <kzaitsev_mb> #topic Open Discussion
17:36:12 <stan_lagun> I have an item for agenda if you don't mind
17:36:19 <kzaitsev_mb> stan_lagun: I believe you had something on your mind =)
17:36:23 <kzaitsev_mb> go on )
17:36:37 <stan_lagun> six library usage in Murano
17:36:57 <kzaitsev_mb> oh right, you never liked it )
17:37:05 <stan_lagun> recently we merged several commits that I'm not completely happy with
17:37:30 <stan_lagun> So I wanted to suggest 2 simple rules that we should follow when using six
17:39:04 <stan_lagun> #1: use six only when absolutely necessary. For example if existing code was iterating over range()/dict.keys()/dict.values() etc. it will still work in Py3. So until the collection is really really large there is no difference between Py2 and Py3 versions
17:39:19 <stan_lagun> the same goes for map(), reduce() etc
17:39:55 <kzaitsev_mb> have no objections to that — seems fair.
17:39:59 <kzaitsev_mb> and probably more readable
17:40:03 <stan_lagun> #2. Never import functions. It shouldn't be "from six import range" but "import six; six.range()"
17:40:52 <kzaitsev_mb> agree to #2 completely. I've actually thought, that hacking role, that checks it is still in place.
17:41:05 <kzaitsev_mb> It's actually still a recomendation from hacking
17:41:31 <kzaitsev_mb> #link http://docs.openstack.org/developer/hacking/#imports
17:41:36 <kzaitsev_mb> Do not import objects, only modules (*)
17:41:52 <stan_lagun> also if some function returned dict.values() Py3 version may not be good because it returns iterator. However list(dict.values()) works in all cases. This is not a rule but a hint
17:42:03 <kzaitsev_mb> I think we should just follow this recomendadtion )
17:42:35 <kzaitsev_mb> ativelkov, freerunner, Nikolay_St_web your opinion on th above ^^
17:42:35 <stan_lagun> yes. And also fix the code that we already merged that doesn't follow those 2 rules
17:42:58 <kzaitsev_mb> stan_lagun: we can actually put it to this doc page
17:43:01 <kzaitsev_mb> #link http://docs.openstack.org/developer/murano/contributing.html
17:43:19 <kzaitsev_mb> so that we would not store this as a tribal knowledge )
17:43:28 <Nikolay_St_web> kzaitsev_mb: I agree here
17:43:36 <stan_lagun> At least we should be careful on code review. Tests will not catch those issues
17:43:54 <Nikolay_St_web> also, we really need to include this in our contributing doc
17:44:13 <kzaitsev_mb> stan_lagun: may I ask you to put those 2 rules on a contributing doc then? =)
17:44:26 <stan_lagun> okay
17:45:06 <kzaitsev_mb> #agreed with stan_lagun's suggestions regarding six usage in murano (see logs for more info =))
17:45:31 <kzaitsev_mb> #action stan_lagun put info on six usage to http://docs.openstack.org/developer/murano/contributing.html
17:45:40 <stan_lagun> kzaitsev_mb: but that page contains links only. There are no code style or something there so it would be strange to start with six :)
17:46:00 <Nikolay_St_web> stan_lagun: that's ok
17:46:04 <kzaitsev_mb> stan_lagun: well, I think that would be a good place to start adding those
17:46:29 <Nikolay_St_web> this docs usually has links to general guidelines and some additional project-related style changes
17:46:45 <Nikolay_St_web> so, why can't we start with six?
17:47:20 <kzaitsev_mb> Nikolay_St_web: yep, we don't have such section yet, so this contributing guide seems like a place as good as any
17:48:05 <freerunner> I think, this will be a good start for contributing guide. =)
17:48:35 <freerunner> Also, agreed with stan_lagun's proposal.
17:49:40 <freerunner> So, since we start speak about contributing guide here, maybe we can also add some rules about murano-apps commit naming?)
17:50:09 <kzaitsev_mb> freerunner: as a separate commit — no problem )
17:50:28 <freerunner> kzaitsev_mb: Yep, ofc this commit should be separated.
17:50:55 <kzaitsev_mb> that's actually a good place where we can gather together some of the tribal knowledge we have
17:51:22 <Nikolay_St_web> kzaitsev_mb: freerunner I guess that murano-apps related stuff should be placed in murano-apps repo
17:52:20 <kzaitsev_mb> freerunner: let's maybe start an etherpad and try to remember what custom rules we have regarding commits and contribution
17:52:27 <kzaitsev_mb> and later transfer that to that article
17:53:23 <kzaitsev_mb> #link https://etherpad.openstack.org/p/murano-contributors-rules
17:54:40 <kzaitsev_mb> if anyone remembers anything else — don't hesitate to add a line there =)
17:54:54 <Nikolay_St_web> kzaitsev_mb: ok
17:55:06 <freerunner> Nikolay_St_web: We haven't doc in murano apps and, respectively, haven't a doc-build job for it. I think, we can put items about murano-apps into contributor's guide in murano repo, because murano-apps doesn't work without murano (Or this thing is wrong? :) ).
17:55:31 <kzaitsev_mb> freerunner: one doc to rule them all )
17:56:03 <kzaitsev_mb> freerunner: we currently have only 1 doc for all murano stuff (including agend and dashboard) so apps fit in nice there
17:57:40 <kzaitsev_mb> ok, that felt like a productive meeting with lot's of AI for the next agenda =) Thanks a lot everyone!
17:58:17 <Nikolay_St_web> kzaitsev_mb: bye
17:59:04 <kzaitsev_mb> If anyone has anything else to discuss, you're always welcome in #murano =)
17:59:07 <kzaitsev_mb> wrapping up
17:59:10 <kzaitsev_mb> #endmeeting