17:00:55 #startmeeting murano 17:00:56 Meeting started Tue Jan 12 17:00:55 2016 UTC and is due to finish in 60 minutes. The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:59 The meeting name has been set to 'murano' 17:01:10 o/ 17:01:45 o/ 17:02:01 o/ 17:02:28 o/ 17:03:32 We have following agenda for today: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda 17:03:34 will get to normal client in 2 minutes 17:03:58 Please add to this agenda anything that you would like to discuss today, we have few minutes while we are on roll call 17:04:42 o/ 17:06:58 here I am =) 17:09:11 #topic Action Items Review 17:09:23 did we have any? =) 17:09:28 http://eavesdrop.openstack.org/meetings/murano/2015/murano.2015-12-22-17.00.html <- meeting minutes from the last meeting 17:09:53 last meeting was so long time ago... 17:10:05 oh right 17:10:07 #1 ativelkov to summarize the plugin usage questions in etherpad 17:10:36 ouch 17:10:42 didn't do that, sorry 17:11:12 #action ativelkov to summarize the plugin usage questions in etherpad 17:11:23 ativelkov: holidays :) no worries ) 17:11:31 #2 release client, stable/liberty updates 17:11:33 ativelkov: which plugin is it btw? 17:11:45 kzaitsev_mb: that's not about a particular plugin 17:11:55 #2 done — 1.0.2 murano and dashboard, 0.7.2 client have been released 17:12:27 That's a general question where should plugins be in terms of pbr packages - should the plugins which we ship with murano be in the same setup.cfg or should they have their own ones 17:12:50 I've also sent corresponding mails before NY to openstack-announce =) 17:14:08 ativelkov: oh, now I remember =) 17:16:25 hey 17:16:30 finally I'm here 17:17:05 I'm here too :) 17:18:23 (= 17:18:39 kzaitsev_mb: =) 17:18:50 traffic jam in the undeground :D 17:18:58 really BIG problem 17:20:33 wow... traffic jam in subway? ) 17:20:51 #topic Abandoning milestones? 17:21:03 will we have bug triage day for everyone who is interested 17:21:16 katyafervent2: mmm? 17:21:19 katyafervent2: ? 17:21:36 ok. so both my topics today are going to be short 17:21:41 katyafervent2: I mean was this question? and how it's relates to the topic of dicsussion? 17:21:57 before mitaka-2 release 17:22:07 horizon has it today :) 17:22:12 a while ago I started this discussion 17:22:15 #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/083113.html 17:22:22 didn't get much response =) 17:22:28 Would like to re-start it 17:22:39 the letter basicaly summs everything up 17:23:03 I've come to think that abandoning milestones is a good idea, and abandoning bps is a bad one 17:23:04 sorry, I typed before you changed the topic, let's discuss it later 17:23:27 katyafervent2: what makes you think we have such a day? I haven't seen any announcements. 17:24:07 kzaitsev_mb, it was a question. sorry 17:24:08 I mean. if you want to have one — we should at least write a letter to ML or smth 17:24:14 oh I see 17:24:30 ok. 17:24:31 so 17:24:52 I still don't see a reason have one, and think that they are total waste of time :) 17:25:08 pls find some time and think about my proposal regarding milestones and bps =) 17:25:24 regarding abandoning milestones 17:25:38 kzaitsev_mb: Yeah... I missed fact that we can have different versions in different projects 17:26:10 sergmelikyan: that's basically what we have now with murano-agent 17:26:33 I suggest to postpone it a little bit and continue to set milestones for now 17:26:35 the new scheme for stable branches allows us to have 1.0.1 murano-agent and 1.0.2 murano-dashboard for example 17:26:43 katyafervent2: why? 17:26:52 I mean 17:26:56 the only good thing about milestones is that by looking at LP ticket for commit you always know in which release the feature was introduced 17:27:26 I'd make milestones be just "mitaka" rather than m1 etc 17:27:31 if you have any good points — pls respond the letter =) 17:28:07 slagun: that's a good point actually. although wouldn't series cover it? 17:28:14 until handling with new versions become understandable to everyone. I think it is still a transition period :) 17:28:57 and for that period I support Stans suggestion 17:29:06 kzaitsev_mb: agree. Either series or milestones. There should be only one :) 17:31:17 kzaitsev_mb: can we move to the next topic? 17:31:45 sure =) I just hope, that those of you who have some opinion on the topic would find some time to answer the email ) 17:31:51 #topic Do we need any release model changes? 17:33:27 ok, so this is also gonna be a short one 17:33:43 and it's kind of related to the previous 17:34:06 Thierry wrote a letter recently about release model freeze around m-2 17:34:15 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/083726.html 17:34:18 so 17:34:43 if we would like to change a release-model of any of our project we should act in the following two weeks 17:35:34 we currently have 17:35:36 kzaitsev_mb: let's vote on next community meeting 17:35:57 kzaitsev_ip_: do you think that we need change? 17:36:04 I think this change is required for all official projects right ? 17:36:15 #link https://github.com/openstack/governance/blob/561c848b481ad6008b0d484d5f609930f2e11a7d/reference/projects.yaml#L1979-L2023 17:37:19 we might want to switch our cycle-with-milestones to cycle-with-intermediary 17:37:31 katyafervent2: I guess no, we don't have to change anything 17:37:45 and we might want to move murano-apps to release:independent 17:37:46 kzaitsev_ip_: what is the benefit of doing that in our case? 17:37:56 >and we might want to move murano-apps to release:independent 17:38:24 I think we should continue releasing murano-apps tied to murano releases 17:38:55 I actually think murano-apps might even be release:none, but have 17:39:05 release:has-stable-branches 17:39:32 agree with kzaitsev_mb here 17:39:35 this would be more appropriate representation of how we handle murano-apps 17:40:04 that would mean we don't actually deliver a tarball or smth, but still have stable-branches, that are supported for respective murano releases 17:40:08 kzaitsev_ip_: disagree 17:40:18 +1 17:41:32 kzaitsev_ip_: release:cycle-with-milestones does not relate to delivery method 17:41:45 and we usually build zip archive with all apps 17:42:15 #link http://governance.openstack.org/reference/tags/release_cycle-with-milestones.html 17:42:21 well who needs that zip? 17:42:30 I mean does anyone ever use it? 17:42:33 whole murano-apps is a single entity, which contains several applications versioned toghether... we discussed this previously, but I guess we need to summarize that in e-mail and continue to discuss if needed 17:42:54 kzaitsev_ip_: guess, how many people downloaded tarballs with murano? 17:43:01 1-2 in months? 17:43:16 question is not what you attach to the launchpad page 17:43:28 I agree with Kirill, I haven't ever use Mirantis-apps tarball 17:44:09 release:cycle-with-milestones does not say anything regarding how you deliver staff 17:44:15 it says how do you release that 17:44:36 sergmelikyan: "The “release:cycle-with-milestones” tag describes which projects follow the first option: a single release at the end of the cycle" 17:44:43 and I think that we should continue releasing murano-apps in a same way as before - alongside with Murano 17:45:00 kzaitsev_ip_: yep, and? 17:45:57 sergmelikyan: thats what stable branches mean. Each stable branch corresponds to murano release. But there is no need for either milestones or tarballs for murano-apps 17:46:32 ok, maybe we're not really understanding each other or not understanding the release model 17:47:07 sergmelikyan: do you want me to ping release team (thierry and dhellman) to clarify on the topic? 17:47:35 slagun: in murano-apps we often use features from Murano right away when they are developed 17:48:12 sergmelikyan: so what? 17:48:16 kzaitsev_ip_: I guess we should start from understanding on our side regarding what is actually you want to archive and then see which reelase model suits better 17:48:23 sergmelikyan: from what I understand murano-apps do not have a "release" 17:48:50 kzaitsev_ip_: can you share what do you consider a release? 17:49:04 in my opinion tag in GIT is a release 17:49:25 stable branches must work on corresponding version of murano. master must work on current muster 17:49:27 so when we cut milestone in murano-apps we are making release 17:49:54 we make release by creating stable branches 17:50:08 slagun: not exactly milestone is also release 17:50:15 just beta release 17:50:57 I'd preffer each commit to be a beta release. That is continuous delivery 17:51:05 let me take action item to describe my vision regarding versioning of murano-apps, and when we will agree on that - let's talk about changing release model 17:51:26 sergmelikyan: will you write a letter in ML? 17:51:33 Nikolay_St: yes 17:51:36 ok, agree on that 17:52:15 I'll still reach out to the release-team to see if my idea (has-stable, release:none) even makes sense from their perspective =) 17:52:19 #topic sergmelikyan describe versioning model for murano-apps 17:52:35 should be action ;) 17:52:43 kzaitsev_ip_: I would prefer to describe how do we want to version murano-apps first 17:52:50 it's not described anyware 17:53:05 #action sergmelikyan describe versioning model for murano-apps 17:53:05 describe versioning model for murano-apps 17:53:13 #topic Open Discussion 17:53:16 ok, sure ) 17:54:41 so a couple of news — dashboard translation commit is stuck until infra guys decide on the new spec for dashboard-like repos 17:55:18 2) rohini has submitted an initial patch with support for osc =) which is awesome, pls give it some time and play with it 17:55:41 #link https://review.openstack.org/#/c/266018/ 17:55:57 I mean the fact that there is such a commit is awesome =) 17:56:15 gotta check the awesomness of the commit before saying that it is ) 17:57:14 i will itegrate the commands soon. 17:58:16 enthurohini: oh =) cool, didn't notice that you joined ) 17:58:28 kzaitsev_mb, i have implemented single command, should i commit for review or wait untill i complete a group of command? 17:59:02 I'd suggest you would add another commit atop the 1st one, that adds a group of commands ) 17:59:09 kzaitsev_mb, i joined but was late. :P 17:59:49 ok 18:00:04 kzaitsev_mb: enthurohini can you share a link to the review? 18:00:22 Nikolay_St: I just did ^^ 18:00:31 kzaitsev_mb: my bad 18:00:34 TIME 18:00:43 it'll be in meeting notes ) 18:00:50 #endmeeting