17:02:07 <sarob> #startmeeting training-guides
17:02:08 <openstack> Meeting started Mon Jan 12 17:02:07 2015 UTC and is due to finish in 60 minutes.  The chair is sarob. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:13 <openstack> The meeting name has been set to 'training_guides'
17:02:17 <dguitarbite> hello
17:02:19 <sarob> ello people
17:02:22 <sayali> hey
17:02:23 <timfreund> hello
17:03:16 <sarob> i have an outstanding task from last meeting
17:03:43 <sarob> to propose adopting nova core reviewer standards on the ML
17:03:57 <sarob> other than that is review the status of specs
17:04:07 <sarob> we have a few new and one blocker
17:04:48 <matjazp> hey
17:04:55 <sarob> when matjazp and rluethi join we can vote on adopting the core reviewer
17:05:01 <sarob> matjazp hey
17:05:02 * rluethi is here
17:05:05 <sarob> cool
17:05:20 <sarob> #topic adopting nova core reviewer standards
17:05:49 <matjazp> isn't that more the process of electing new cores?
17:06:26 <sarob> everyone familar?
17:06:28 <rluethi> what matjazp said
17:06:44 <sarob> rluethi hey back at you
17:06:50 <sarob> opps
17:06:58 <sarob> matjazp yes
17:07:05 * sarob digging for link
17:07:17 <rluethi> so what will change for us, and what is that standard good for?
17:08:09 <sarob> #link https://wiki.openstack.org/wiki/Nova/CoreTeam
17:08:38 <matjazp> for the *process*, I believe we have an agreement among us
17:08:41 <sarob> rluethi: means that anyone can be proposed as a new core on the ML
17:09:17 <sarob> from the nova wiki
17:09:23 <rluethi> sarob: how is this different? that is already the case.
17:09:24 <sarob> A new member may be proposed on the openstack-dev list at any time. A proposal can come from anyone, but typically comes from the project's PTL or an existing member of the core team. Once a proposal has been made, five existing members of the core team must respond with a +1. If any existing member of the team objects, they may respond to the proposal with a -1 to veto the nomination.
17:09:25 <sarob> A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership.
17:10:13 <sarob> i think informally we were doing this
17:10:17 <rluethi> not necessarily my preferred method with such a small team (I think the nova method makes more sense for a much larger team).
17:11:00 <matjazp> sarob: yes, we just make it official and thats it
17:11:32 <sarob> so its either the existing cores propose or anyone can request
17:11:37 <rluethi> I'm not a big fan of introducing formal rules unless they are necessary, but if it makes you guys happy I won't stand in the way of progress.
17:12:09 <sarob> being core can become a big deal for some, for others no big deal
17:12:35 <sarob> rather than waiting until it becomes a big deal
17:12:50 <sarob> and since it was brought up last month
17:12:56 <sarob> im following up here
17:13:26 <sayali> there will be no harm to formalize the process either way
17:13:45 <sayali> so everyone is aware of what is required to get there
17:13:47 <sarob> i dont have strong opinion on open nomination or core's nomination
17:14:00 <sarob> sayali: my thought as well
17:14:49 <sarob> so lets get some feedback on: open nomination or core's nomination
17:14:56 <sayali> though we might need to have to lower the bar on the number of +1 required since we are a small team
17:15:37 <sarob> sayali, right
17:17:37 <sarob> any comments on either cores nominate new cores
17:17:47 <sarob> or anyone can nominate new cores?
17:18:38 <matjazp> lest just use the text from nova: anyone, but usually its a core that starts a nomination
17:19:03 <matjazp> its is not so important, as you need to have +1s from cores anyway
17:20:00 <sarob> anyone else?
17:20:42 <rluethi> I would like people to try and find informal ways to find out whether a candidacy has chances.
17:20:59 <sarob> id change the five cores to approve to all cores with any one core having a veto option
17:21:15 <sarob> rluethi like?
17:21:29 <dguitarbite> I agree with you sarob
17:21:41 <rluethi> sarob: talk to core reviewers in private, for instance.
17:24:08 <rluethi> mind you, I don't want this understood as another requirement for candidates. I just want to spare them the anxiety of a public vote (especially when it turns out negative).
17:24:44 <sarob> rluethi, understood
17:25:58 <sayali> I agree with rluethi
17:27:24 <sarob> dguitarbite, matjazp: what do you think of rluethi's point?
17:28:43 <sarob> since the team is still small, we can manage the nomination of a new core very quickly without embarrassing anyone
17:28:59 <matjazp> sure, I'm all for it
17:29:51 <sarob> i think once we become a larger team, like 20 active contributors, then the nova core process makes sense
17:30:37 <dguitarbite> sarob: it depends on the size of the team
17:31:14 <sarob> dguitarbite: more specific please
17:31:24 <matjazp> sarob: in small team, "all cores" requirement is ok, but later, with bigger core team, we should define a smaller number of +1's
17:31:46 <sarob> matjazp: agreed
17:32:10 <sarob> im thinking i post to the wiki
17:32:27 <rluethi> sorry guys, gotta run. If you are going to have a vote on such a formal method, whatever it may be, you can record an "abstain" for me :-).
17:32:53 <sarob> rluethi sure we can wait
17:33:32 <matjazp> sarob: so if we define 5 +1s now, we have basically "all cores" requirement and later we don't need to change rules
17:34:57 <dguitarbite> sarob: it actally depends if we need strict policies or rules. It may come in our way
17:35:02 <dguitarbite> as our team is fairly small
17:35:27 <dguitarbite> that is what I meant, although it makes sense to adopt Nova's policies, Roger has a stronger point here
17:35:39 <sarob> while the team is under 20 active contributors in the last 30 days, new core nominations will be from the existing cores. all existing cores must agree to accept the new core. after the team passes the 20 active contributors for the last 30 days, then we adopt the nova core contributor process
17:36:01 <matjazp> sarob: to complex
17:36:41 <matjazp> sarob: theres no need for such a formal definition
17:36:48 <sarob> matjazp okay just the first part then without the 20 stuff
17:37:01 <sarob> new core nominations will be from the existing cores. all existing cores must agree to accept the new core.
17:37:10 <sarob> pretty simple
17:37:27 <sarob> same for removing an existing core
17:37:35 <matjazp> sarob: nova's formulation is also very simple. 5 +1s, no veto
17:38:28 <sarob> matjazp: any core can veto from my read
17:38:41 <sarob> matjazp for nova core process
17:39:14 <matjazp> that's the same as you are proposing?
17:39:24 <sarob> nope, sorry
17:39:29 <matjazp> "all existing cores must agree to accept the new core."
17:39:35 <sarob> right
17:39:52 <sarob> this is my proposal for accepting new cores
17:40:15 <sarob> new core nominations will be from the existing cores. all existing cores must agree to accept the new core. To remove an existing core, all existing cores must agree.
17:40:35 <sarob> easy peazy
17:40:54 <matjazp> yes, currently its the same also: there are 5 active cores + collin
17:41:28 <matjazp> sarob: when we grow, "all" core will be a tough restriction
17:41:59 <sarob> matjazp: true, but I think we will need more like nova process then anyway
17:42:32 <sarob> can we table this until next week so we can discussing branching for a few
17:42:43 <matjazp> sarob: sure
17:43:06 <sayali> yep
17:43:17 <dguitarbite> sarob: I agree with you
17:43:20 <sarob> #action saob bring add/remove core process at next meeting
17:43:25 <dguitarbite> it should work till we have more core's in the team
17:43:43 <sarob> #topic branching
17:43:58 <sarob> dguitarbite: status on #link https://review.openstack.org/#/c/141369/
17:44:11 <sarob> dguitarbite: how goes it?
17:44:17 <dguitarbite> andreas is back, met him today
17:44:24 <sarob> sweeeet
17:44:26 <dguitarbite> but it may take till the end of January
17:44:36 <dguitarbite> we have openstack meetup which I am organizing with him
17:44:53 <sarob> dguitarbite: ugh
17:44:53 <dguitarbite> so the branching will take time, unfortunatly
17:45:07 <dguitarbite> but I cannot do much here, my hands are tied
17:45:09 <sarob> dguitarbite: the meetup part is good
17:45:18 <dguitarbite> end of January is the worst case
17:45:28 <dguitarbite> and yes, I am giving a talk in the meetup on openstack training.
17:45:44 <sarob> dguitarbite: we will need to branch juno pretty soon after icehouse
17:46:07 <sarob> dguitarbite: once the slides are all pushed and osbash switch updated
17:46:21 <sarob> dguitarbite: is this just branching startup costs
17:46:34 <dguitarbite> yes, I agree
17:46:38 <sarob> dguitarbite: or going to be difficult for each time we branch
17:46:47 <dguitarbite> sarob: this is the first itme
17:46:49 <dguitarbite> *time
17:46:53 <dguitarbite> so its a bit icky
17:46:57 <sarob> dguitarbite: okey dokey
17:47:11 <dguitarbite> next time, I will push the spec really early
17:47:14 <sarob> icky is slow
17:47:18 <dguitarbite> so that we do not repeat the history
17:47:32 <dguitarbite> sarob: winter break did not help either
17:48:00 <sarob> dguitarbite: so can you work out the juno branch at the same time
17:48:07 <dguitarbite> sarob: yes
17:48:29 <sarob> dguitarbite: maybe annegentle wants another bp for the juno branch?
17:48:48 <dguitarbite> sarob: it will be easier, this blueprint charts the plan for getting in sync with Kilo
17:48:53 <sarob> dguitarbite: id like to publish kilo with the release cycle
17:49:04 <sarob> dguitarbite: kilo oh
17:49:10 * sarob rereading
17:49:18 <dguitarbite> yes, thats the end goal
17:49:44 <sarob> dguitarbite: hmm, okay
17:50:02 <sarob> let move on then
17:50:13 <matjazp> dguitarbite: this is pretty slow process.. maybe we should just skip juno and go for kilo instead
17:50:30 <dguitarbite> matjazp: yes, but we agreed on this
17:50:45 <dguitarbite> it is a bit of rough ride for now
17:51:03 <dguitarbite> I'm sure it will get much better for the next release
17:51:17 <matjazp> what I7m afraid is that we will never really catch up
17:51:23 <sarob> dguitarbite, matjazp: unless real problem, id rather not have release gap
17:53:06 <sarob> dguitarbite: if we cannot get juno branch cut by mid feb then lets revisit
17:53:35 <dguitarbite> sarob: let me speed up the process a bit and tell you by next meeting
17:53:45 <dguitarbite> if its possible to branch juno by mid Feb
17:53:54 <dguitarbite> and I think this should be a team decision too
17:54:18 <sarob> dguitarbite: thanks, if not then perhaps we should be cutting juno now instead of icehouse
17:54:29 <sarob> dguitarbite: would be alot less confusing
17:54:41 <sarob> dguitarbite: with update to osbash
17:55:07 <dguitarbite> sarob: yes
17:55:09 <sarob> #topic any other specs need discussing
17:55:14 <matjazp> sarob: yes, that could be better solution.. dguitarbite: is it possible to update osbash?
17:55:28 <sayali> I need inputs on the next video that is coming up
17:55:38 <dguitarbite> matjazp: I think roger needs to answer this
17:56:28 <matjazp> dguitarbite: ok
17:56:32 <sayali> I have written the script down towards to end on the etherpad: https://etherpad.openstack.org/p/openstck-training-guides%28Audio_Visual_Content%29
17:57:55 <sarob> could start pushing the video script as a patch?
17:58:20 <sarob> sayali: then as the video gets developed, you can push the youtube link?
17:58:37 <dguitarbite> time check 2 minutes!
17:58:38 <sayali> umm I don't think that would be necessary sarob for review atleast
17:59:03 <sarob> sayali: that way others can review the video script and give feedback
17:59:05 <sayali> Also reviewing videos and changing them is a big hassel
17:59:12 <matjazp> sayali: script can be also less detailed.. just write "bullet" points
17:59:15 <sarob> sayali: etherpad is okay, gerrit is better
17:59:30 <sarob> times up
17:59:47 <sarob> ill limit the admin stuff to 15 min next time
17:59:59 <sayali> ok cool
18:00:00 <sarob> keep discussing on docs channel
18:00:06 <sarob> cheers
18:00:13 <sarob> #endmeeting