14:00:37 #startmeeting Glance 14:00:38 Meeting started Thu Nov 20 14:00:37 2014 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:41 The meeting name has been set to 'glance' 14:00:44 o/ 14:00:50 o/ 14:00:58 * flaper87 loves this new meeting time 14:01:08 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:11 o/ 14:01:16 flaper87: this is still the old one 14:01:23 \o 14:01:27 o/ 14:01:27 flaper87: we can have the new time starting oct4th 14:01:38 is this the new time? I though the new one is 30 mins later, is not it? 14:01:42 nikhil_k: I'd prefer bit earlier 14:02:00 s/this/the/ 14:02:14 Oct 4th is after all almost year away 14:02:14 o/ 14:02:14 o/ 14:02:44 probably that is Dec, not Oct 14:02:45 jokke_: heh, oops 14:02:49 I meant Dec4th 14:02:58 nikhil_k: better ;P 14:03:27 * nikhil_k is probably still half asleep in this cold morning 14:03:55 the proposal was 14:30UTC to accomodate different people 14:04:15 that way everyone(most) get to attend at least half of it 14:04:20 vs. nothing at all 14:04:36 maximum votes are for 15:30 - which is fine too 14:04:56 nikhil_k: it's too late to me.. 14:05:21 zhiyan: can you add yours here real quick http://doodle.com/nwc26k8satuyvvmz ? 14:05:22 nikhil_k: 15:30 is bit late for me as well ... most of the time I'm on the road at that time 14:05:28 what is UTC now? 15? 14:05:32 that way we can make a quantifiable decision 14:05:33 ativelkov: 1400 14:05:50 ativelkov: 14 14:05:54 got it 14:06:32 am using the new today feature with different clocks (osx yosamite if it helps) 14:06:57 anyways, if zhiyan puts 14 on the doodle then we've a tie with 15:30 14:07:37 with no real distinguishing factor to say which one should we prefer 14:08:13 would everyone be okay to alternate between 14 and 15:30 in that case? 14:08:21 If we can at least do 14:30, that'd be better for middel and west coast. 14:08:38 jokke_: ^ 14:08:51 \s\middel\middle 14:09:06 #startvote would everyone be okay to alternate between 14 and 15:30 in that case? 14:09:07 Begin voting on: would everyone be okay to alternate between 14 and 15:30 in that case? Valid vote options are Yes, No. 14:09:08 Vote using '#vote OPTION'. Only your last vote counts. 14:09:30 #vote yes 14:09:33 #vote yes 14:09:33 #vote yes 14:09:37 #vote yes 14:09:58 #vote yes 14:10:09 #vote yes 14:10:43 #yes 14:10:59 #vote yes 14:11:19 #vote yes 14:11:20 #vote yes 14:11:33 #vote yes 14:11:53 that number shoukd be more than enough I sup (without any serious objections) 14:12:03 * TravT gives into yes pressure. :) 14:12:16 TravT: there's no pressure :) 14:12:21 still time 14:12:30 nikhil_k: looking your doodle 1400 has most votes :P 14:12:30 Every other week is reasonable 14:12:50 oh, lakshmiS added vote too 14:13:00 thanks 14:13:25 TravT: how likely is wayne going to be attending the meetings? 14:13:34 if we can find compromise so we don't need to alternate I think it would make everyones life easier 14:13:40 #endvote 14:13:42 Voted on "would everyone be okay to alternate between 14 and 15:30 in that case?" Results are 14:13:51 but that does not sound too likely 14:14:00 jokke_: +1 14:14:05 was thinking 14:30 14:14:13 14:45 ? 14:14:21 but then zhiyan says no and I find his importance significant to the meetings 14:14:48 s/no/yes 14:15:11 :) 14:15:29 TravT: jokke_ : mind syncing up a bit later after the meeting 14:15:30 zhiyan succumbs to pressure 14:15:43 we'd finilize the time today,(think) 14:15:49 nikhil_k: sure. 14:16:03 nikhil_k: yup ... sent you PM about that already ;P 14:16:27 hemanthm: no, i can join the meeting which i can join..not a big deal 14:16:29 #topic updates 14:16:43 so, in the interest of time, will quickly say these here 14:17:10 we've had good number of volunteers/interest groups for https://wiki.openstack.org/wiki/CrossProjectLiaisons 14:17:15 and that's good 14:17:43 as the TC wants more people to be "empowered" to take important decisions to the different aspects of projects 14:18:25 with power comes responsibility hand in hand, hence the liaisons would be strongly encouraged (not sure if expected) to attend a weekly meeting 14:18:39 CPL meeting which will replace the existing "project" meeting 14:18:50 who is going to be the QA liaison for Glance? 14:19:21 curtis_p ? 14:19:29 if no one vounteers it's me however, we've had some interest from curtis_p , not sure if he's still interested 14:20:08 I am interested 14:20:14 +1 14:20:15 Not sure about the scope 14:20:22 for the stable branch liaisons, it made sense to ask jokke_ first and he's (at least partially) accepted the role 14:20:48 (as his interest and full time responsibilites suit the purpose) 14:21:17 (just so that it's not a news when the wiki is populated) 14:21:38 #topic kilo-1 14:21:44 #link http://status.openstack.org/release/ 14:22:01 we need some BPs to be priorotized (even if spec is not approved yet) 14:22:06 to be marked to k-1 14:22:39 so, please let me know if anyone is interested in having theirs else it would be totaly judement call from my side 14:22:46 if the spec is not approved, we don't have the BP, do we? 14:22:48 o/ 14:22:54 judgement* 14:23:06 how about the multiple containers one? :) 14:23:22 how about store-capabilities one? :) 14:23:23 its close to getting approved as well, I think 14:23:32 hemanthm: sure 14:23:50 ativelkov: bp is on launchpad, so is independant of the spec being approved 14:23:53 i mentions it durning the summit, and folks see it sensible 14:23:53 iirc 14:24:07 zhiyan: do you mean https://review.openstack.org/#/c/126550/? 14:24:18 I'd seriously like to see that glance_store integration prioritized 14:24:21 nikhil_k: no 14:24:37 ativelkov: some people have already created one, so let's discuss a bit after the meeting on that 14:24:42 nikhil_k: it's a change for glance_store, but different than api ref 14:24:48 kragniz: when we had specs introduced there was an idea that BP is automatically (?) created as soon as spec is merged. But probably I got something wrong 14:25:03 nikhil, 14:25:14 that's my understanding too, ativelkov 14:25:22 are you talking about getting spec approved by kilo 1 or about getting all code landed in kilo 1 14:25:23 ? 14:25:24 ativelkov: yeah, not sure how effectively that's being used. at least release maangement becomes difficult 14:25:43 TravT: landed by k1 14:25:53 ativelkov: I think that was the original idea but until that happens we're relying on people who is submitting spec opening bp on lp with the same name as the spec file and crosslinking them together 14:25:54 that would essential mean spec is approved 14:26:32 so, if you all think that the spec can land in k1 - we can priorotize it given there are enough slots available 14:26:34 got it. Then, I'll create a BP for artifacts spec (which needs to be updated anyway) 14:26:49 ok. Well, I think the metadefs tag support will be ready by Kilo 1 14:26:55 code and spec 14:26:55 jokke_: I see, I should create one for multiple containers then, thanks! 14:27:46 ok, cool. we can potentially have 1 big, 1-2 medium and upto 3 small specs by k1 14:28:13 sorry, need to rush a bit 14:28:21 there is example in todays agenda you can use as reference (Surprisingly the logging refactoring 14:28:25 #topic Mini-summit 14:28:53 nikhil_k: should we just open a launchpad blueprint and link to spec for now? 14:28:59 so, the update is that people would be communicated that these summits are optional and cores are not expected to attend 14:29:04 TravT: yes 14:29:06 ok 14:29:32 that's just fyi - so the purpose of the mini-summit is clear and people do not feel obligated 14:30:01 nontheless, we can strongly encourage the core memebers to be present as that seems important for taking decisions 14:30:16 and about the time and venue 14:30:40 we've very likely to have it in Palo Alto (After) the Nova mid-cycle meeting 14:30:47 or may be overlap one day 14:30:55 any company can give me a founding to attend ? 14:30:59 the details are not clear as I'm yet to hear from the Nova PTL 14:31:09 :) IBM 14:31:16 +1 to zhiyan 14:31:20 (Sorry I'm late) 14:31:21 what's the agenda? Is that only nova's v1->v2 migration? 14:31:22 and the VMware repr who is arranging is sorting out the details 14:31:23 lol 14:31:28 so the plan is still tentative 14:31:52 we'd get the confirmation in near future (hope) 14:32:17 nikhil_k: can we art least lock it now to end of so I can start planning my other travel beofre that? 14:32:32 enf of January it is 14:32:49 we can say it's end of January 14:32:58 thnx 14:32:59 without confirmed time and venue though 14:33:10 (time as in date) 14:33:30 nikhil_k: as long as I know it's not gonna happen like 10-13th or something like that I'm fine ... 14:33:46 jokke_: yes, not then 14:33:48 #topic Progress on review guidelines? 14:34:06 that'd be me I guess 14:34:15 yes 14:34:23 or anyone else too 14:34:31 mfedosin and I are working together on putting together a wiki page that ativelkov talked of before 14:34:41 (have a few comments, after) 14:35:02 I'm still collecting content, so there's nothing up on the wiki yet 14:35:25 hope to get it into a decent shape and have the first version ready soon 14:35:38 hemanthm: seems it's a good idea, pls let me know when it/draft ready if you ok. 14:35:47 is there a deadline of sorts on this one? 14:35:48 I just want to make sure that we do not duplicate anything which is already present on primary openstack wiki 14:35:48 hemanthm: is that content coming from the etherpad from last weeks meeting? 14:35:50 zhiyan: sure 14:35:54 ativelkov: +1 14:35:55 hemanthm: thanks 14:36:07 kragniz: that's a part of it 14:36:13 hemanthm: cool 14:36:30 ativelkov: sure. 14:36:38 hemanthm: I'm sure you know about this https://wiki.openstack.org/wiki/ReviewChecklist, looks like something we could link off 14:36:52 mfedosin and I are going to meet soon on this topic, if anyone wants to join please let us know 14:37:17 +1 14:37:17 talking about reviews 14:37:27 +1 14:37:35 #startvote do we need cores? :) 14:37:36 Begin voting on: do we need cores? Valid vote options are , . 14:37:37 Vote using '#vote OPTION'. Only your last vote counts. 14:37:48 (more core reviewers) 14:37:49 mclaren: thanks for the pointer, I was mostly looking at the nova one 14:38:24 nikhil_k: how many cores in general in os community? 14:38:37 #vote yes 14:38:38 kragniz: yes is not a valid option. Valid options are , . 14:38:38 #vote yes 14:38:39 jokke_: yes is not a valid option. Valid options are , . 14:38:40 #vote yes 14:38:41 TravT: yes is not a valid option. Valid options are , . 14:38:43 #vote yes 14:38:44 hemanthm: yes is not a valid option. Valid options are , . 14:38:44 #vote yes 14:38:45 lol 14:38:45 cpallares: yes is not a valid option. Valid options are , . 14:38:52 lol 14:38:54 I'd say we need mote reviews. People often start reviewing as soon as there is at least one +2 14:39:04 zhiyan: we don't have many core reviewers atm 14:39:06 openstack doesn't want more cores, boo 14:39:13 I'm not sure more in numbers is needed, but activity would be nice 14:39:17 https://review.openstack.org/#/admin/groups/13,members 14:39:24 jokke_: +1 14:39:25 jokke_: ++ 14:39:28 zhiyan: yes, am working on that list 14:39:50 #vote yes 14:39:51 lakshmiS: yes is not a valid option. Valid options are , . 14:40:02 how many of those cores are active? 14:40:06 jokke_: promise to be more active once we sort out the crtical stuff for Glance atm (prolly in a week) 14:40:11 ok good 14:40:15 #endvote 14:40:16 Voted on "do we need cores?" Results are 14:40:18 http://stackalytics.com/?module=glance-group 14:40:31 so, we can plan to add more people in a staggered manner 14:40:50 so that we do not have rush of commits into the tree 14:41:03 and that's the part of the guideline I wished to add 14:41:36 please take care of how many and what types of commits go into the tree (once the nominated members become core) 14:42:11 for first step we can add 2 members of different interests so that we've momemtum on wide set of patch sets not just single type 14:42:35 and after 3 weeks we can decide on more, I'm sure there are a lot of great candidates waiting for the role 14:42:50 that was it from my en 14:43:06 what about spec cores? 14:43:15 drivers you mean? 14:43:18 spec cores == drivers? 14:43:27 there's two different lists 14:43:30 nikhil_k: as there seems to be lots of folks looking pure numbers, should we think cleaning some out of the list from the inactive end?\ 14:43:51 https://review.openstack.org/#/admin/groups/342,members 14:44:08 so, the problem there is that we do not want a dozen people there as it would create chaos. the current list is def a bit small though 14:44:12 jokke_: working on it 14:44:34 nikhil_k: we can send mail to ML first 14:44:48 before clean 14:45:11 zhiyan: not ML 14:45:24 they are veterans 14:45:40 and deserve respect 14:46:05 #topic reviews, specs, etc to be discussed 14:46:23 nikhil_k: ok, i mean before do the cleanup the list , just send mail to make folks know.. 14:46:30 zhiyan: sure thing 14:46:38 #link https://review.openstack.org/#/c/130839/ 14:46:44 nikhil_k: i think you read me wrong.. 14:47:03 zhiyan: sorry O:-) 14:47:19 who added that? 14:47:30 he's not here 14:47:51 jokke_: Logging/translations refactoring ? 14:47:57 nikhil_k: and that PS is in merge conflict, so pointless pushing effort on that before it's solved 14:48:07 jokke_: ohk yes 14:48:19 nikhil_k: yes ... blunt question, should I just abandon that change? 14:48:20 I was collecting a list of reviews that need some love 14:48:29 https://review.openstack.org/#/c/116626/ 14:48:29 https://review.openstack.org/#/c/132113/ 14:48:30 https://review.openstack.org/#/c/123769/ 14:48:50 #link https://review.openstack.org/#/c/116626/ 14:48:54 #link https://review.openstack.org/#/c/132113/ 14:48:55 the list was rather long last night, but some fine folks merged them (and stole my thunder :P ) 14:48:58 #link https://review.openstack.org/#/c/123769/ 14:49:27 these MPs have been sitting there for a while, looking good and getting rebased 14:49:46 ok, may be some food for the cores 14:50:15 I know the first one is bit mouthful 14:50:16 (fast food, ) 14:50:16 nikhil_k: please nom them 14:50:50 i'd like to take a look on #116626 14:51:03 but it has been sitting there rebased for months with various amounts of +1/+2 just consuming lots of time rebasing as it touches bit of everything 14:51:07 seems that's the blocker now 14:51:12 cool, I will try to review them today/tomorrow. rest is up to the other members 14:51:31 zhiyan: thanks, would be greatly appreciated 14:51:35 sigmavirus24: are the other links added by you ? 14:51:38 jokke_: yrw, man 14:52:08 nikhil_k: I just wanted the meeting bot to record those links 14:52:13 I think anyone can #link something 14:52:15 TravT: will try to review the tagging spec on priority 14:52:23 ah ok 14:52:35 (I think ;)) 14:52:40 on priority? 14:52:47 sigmavirus24: the bot has started id-ing the links without that tag (think) 14:52:56 ah okay 14:53:00 TravT: :) 14:53:01 as oslo liaison, i'd like to see i18n stuff be syncup asap as well, btw jokke_ 14:53:18 TravT: I meant, not in 2 weeks, sometime sooner than that 14:53:22 zhiyan: https://review.openstack.org/#/c/132113/ you mean? 14:53:32 yes 14:53:48 on that one, i'm actually looking to get a core to agree to review the code 14:53:49 sigmavirus24: yes 14:53:50 #topic Open discussion 14:53:51 as per the guidelines 14:53:56 and https://review.openstack.org/#/c/117204/ 14:54:04 let's discuss the rest of the stuff under this topic 14:54:09 https://review.openstack.org/#/c/132113/ would be nice to have more people's opinions on 14:54:28 I've a question on functional tests 14:54:31 sigmavirus24: yeah, and that's dependant on the rest of jokke_'s changes 14:55:18 ugh sorry, wrong link, I meant to link to https://review.openstack.org/#/c/134810/ 14:56:00 TravT: ah ok, just read that. not sure what the ideal way to do it 14:56:20 sigmavirus24: thanks for update ... will have a look on that tonight 14:56:29 Thanks jokke_ 14:57:12 I've got some QA guys willing to write functional tests for artifacts (and probably more, if we miss some tests in other areas - they have time to contribute). However, I am not sure what is the proper workflow for this? May the tests be added as a separate changeset, or should they come as part of the primary changeset which adds feature code? 14:57:54 so quick proposal when we're doing guidelines for reviews etc. How about making sure when setting bug priority to confirm the bug as well. Seen lately bugs popping up to medium/high priority that are not clear if they are real or triaged at all 14:58:07 jokke_: +! 14:58:09 *+1 14:58:26 I'd really like to see a group of us get together once a week or something and walk through the bugs 14:58:32 sigmavirus24: +1 14:58:35 So would be nice if the person who prioritizes bug would also confirm it or if no time for that, not also then setting the priority for it 14:58:35 ativelkov: primary set sounds good to me 14:58:37 See if we can confirm/triage/prioritize things before random people start working on them 14:58:44 we sort of did that this week 14:58:49 and it worked well 14:58:54 kragniz: yeah, I'd like to keep it up to 14:58:56 ativelkov: it wouldn't make sense to let the code sit without tests 14:58:58 +1 kragniz 14:59:16 saw that activity by several people this week. thanks to everybody doing that 14:59:38 jokke_: can you please come up with a list for the bug priority guidelines? 14:59:46 nikhil_k: sure 14:59:53 thanks 15:00:11 ok, we're out of time 15:00:14 hemanthm: can you add a note to the guidelines to *NOT* work on bugs until they're at least confirmed if not triaged? 15:00:28 sigmavirus24: sure, making a note of that 15:00:34 hemanthm: thank you +1 15:00:38 ok great 15:00:38 thanks all! 15:00:39 nikhil_k: yes, I understand, but this complicates the development: it's easy when the feature developer writes tests for their code, but if these are different people, then co-working on the same changeset may be tricky. Is it possible to push feature with some minimum set of tests and then add more with a dependent changeset? 15:00:41 Thanks all 15:00:57 #endmeeting