20:00:14 #startmeeting barbican 20:00:15 Meeting started Mon Jun 1 20:00:14 2015 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:19 The meeting name has been set to 'barbican' 20:00:25 #topic Roll Call 20:00:38 o/ 20:00:40 heyo/ 20:00:46 \o 20:01:23 \|  ̄ヘ ̄|/ 20:01:25 o/ 20:01:37 chellygel, always something creative ;) 20:01:47 o/ 20:02:15 Not a whole lot of core peeps today. :-\ ... oh well, we'll still have an awesome meeting anyway :D 20:02:21 as usual the agenda can be found here: 20:02:23 #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda 20:02:30 elmiko, life is too short for boring arm raises ;) 20:02:42 chellygel, hells yea! 20:02:45 #topic Vancouver Summit Recap 20:03:07 o/ 20:03:10 The summit was a great success, I think. Thanks to everyone who was able to make it! 20:03:12 o/ 20:03:26 I've collected all the etherpads that were used during the summit at this wiki page: 20:03:31 #link https://wiki.openstack.org/wiki/Barbican/Liberty 20:03:33 no more liquorice though... ;) 20:04:33 I sent out some emails last Friday to contributors who signed up for action items for LIberty, so hopefully y'all received those. 20:05:16 Also, I've started an etherpad for the next Cycle (M), it currently has all the things we punted at the summit 20:05:23 #link https://etherpad.openstack.org/p/barbican-m-design-sessions 20:05:54 Feel free to add any topics for the next summit... ( I know, we're thinking way ahead... ) 20:06:04 any questions/comments about the summit? 20:06:45 big thumbs up to the barbican team =) 20:07:01 thanks elmiko! 20:07:06 o/ 20:07:21 Yeah, I feel we got a lot more done than at the Paris summit. 20:07:34 ok, moving on... 20:07:41 the work sessions were great 20:07:45 #topic New Core Reviewers 20:08:25 In case you missed it on the mailing ilst, we have two new core reviewers: Kaitlin Farr (kfarr) from JHAPL, and Chelsea Winfree (chellygel) from Rackspace 20:08:40 congrats! 20:08:47 well deserved imho 20:08:47 w00t 20:09:05 Congrats! 20:09:06 \o/ :) 20:09:14 thanks! :D 20:09:33 now you know who to bug for +2s and +Workflows 20:09:38 :0 20:09:39 hehe 20:09:41 *\( *ω*)┓ (for you elmiko ) 20:10:01 excellent lol 20:10:04 which brings me to the next topic ... 20:10:10 #topic Is Barbican too Slow? 20:10:35 I had a couple of people at different time express dissatisfaction with the turnaround speed on Gerrit reviews 20:11:16 alee, jaosorior and I were talking about possible solutions to this at the summit 20:11:16 i think that's a fair criticism 20:11:25 elmiko +1 20:11:35 Barbican is not nearly as bad some other projects 20:11:48 kfarr agreed. 20:12:00 o/ 20:12:03 I think that with the new cores, we should hopefully see more reviews. 20:12:19 kfarr, true - but now that we have a number of core reviewers, we can probably do better. 20:12:31 one suggestion that alee jaosorior and I had was around the need for 3 reviewers for a CR 20:12:37 from my perspective, i'm hesitant to review barbican stuff because i'm a little worried about not knowing enough in the domain 20:12:47 ^ i think this is everyone's concern elmiko 20:12:51 haha 20:13:12 at least i'm not alone then ;) 20:13:28 the suggestion was to ask the +Workflow 3rd reviewer to just do a high-level review, not an in-depth one, and trust that the other two core reviewers did their due dilligence. 20:13:49 redrobot, I think 3 reviewers is appropriate for a project like Barbican. 20:13:52 that's why doc reviews are so important...that helps with making sure we have the requirements correct at least. No code knowledge needed 20:14:27 redrobot How does that compare to other projects? 20:14:29 2.5 reviewers 20:14:29 redrobot, what would we define "due diligence" as and "high level" as 20:14:45 chellygel +1 20:14:50 Greetings 20:15:13 due dilligence = line-by-line review, also possibly pulling down the patch and running it locally 20:15:15 woodster_, +1, I could not agree more. We need better and upto date API docs. 20:15:35 high level = not line-by-line, more of a general "does this change make sense for barbican?" 20:15:54 i'm afraid code reviews would take significantly longer if people were pulling down patches though. I think its a good idea, but if the concern is time, that may not solve that issue 20:15:58 jvrbanac, we're the only project which requires 3 reviewers. the compromise here is that we would get the benefit of having several cores being familiar with whats going on, but not a slowdown of the process. 20:16:04 rellerreller almost all other projects only recquire 2 core reviewers. 20:16:04 I'm not sure how many of us have actually pulled changes ? 20:16:50 chellygel: i did for some of the testing patches, but those were easy 20:17:03 My concern is some / most of these won't be easy 20:17:07 I think a 2.5 review sounds good to me. I remember when I first started that I thought it was only 2 core reviews and a workflow. 20:17:10 chellygel: +1 20:17:15 example: my HSM change -- that requires an HSM to actually test 20:17:39 chellygel agreed. thus the "possibly" qualifier. :) 20:17:48 chellygel, sometimes it makes sense to pull a change down and test locally. soemtimes not. 20:17:58 I have not been running changes locally. I thought Gerrit would take of that. 20:18:15 Personally, I expect more reviewers on code that goes into something like a key manager 20:18:18 i understand, but I'd have to say I don't think many people do pull the changes down... easy or hard redrobot / alee 20:18:25 Considering the implications 20:18:29 rellerreller I like to when it's an APIImpact review to actually see the request/response 20:19:04 redrobot Good to know. That's cool. 20:19:14 rellerreller, redrobot - so some of the changes in process we suggested for api changes will help in that regard too. 20:19:40 one approach would be for folks to list the areas they are 'domain experts' or really interested in, and if a CR is reviewed for one of these areas, then at least one of those people should be a +2 or workflow for it. 20:20:03 woodster_ I would think that would increase the bus factor 20:20:14 woodster_ ie. so-and-so isn't here so nobody wants to review the patch. 20:20:18 Well, aside from just changing the number of reviewers -- what are other solutions to this problem? 20:20:20 What is the exact problem? Which part of the process takes the longest? 20:20:29 rellerreller, i think we are on the same wavelength today :P 20:20:30 First review? All reviews? 20:20:46 rellerreller I think the concern was around submitting the patch to finally having it merged. 20:20:49 I have noticed on reviews when one receives a -1 it takes time for the code submitter to address them and submit a new patch. 20:20:50 redrobot: well, I'd hope more than one person signed up for a given area, but no guarantee 20:21:02 from my perspective, the few small patches i submitted had early +1's but then it took awhile to push them over the top. 20:21:10 So, we will receive a -1 and it may take 1 week for them to address the issues and push back 20:21:22 woodster_: Which would leave one having to define an /area/ 20:21:23 but also, when a review has a -1 -- i find that other reviewers do not touch it 20:21:31 chellygel I have seen that too 20:21:43 chellygel: that seems pretty common across projects to me 20:22:08 So, in my mind -- the best solution is to submit a comment to address the -1, or a new patch... that seems to kick things off again. 20:22:35 or asking all reviewers (not just cores) to pick through -1'd reviews as well 20:22:38 chellygel I admit I'm guilty of not clicking through -1s on my dashboard when there's other things to review. 20:23:01 we've also talked about mentioning CRs that need reviews during out weekly IRC...maybe just the top 3 oldest ones perhaps, and celebrating the ones that were merged since last week 20:23:02 I do not review something that has -1. 20:23:09 maybe devote a small portion of this meeting to pointing out reviews that are stagnating? 20:23:12 i have seen patches get up to 10+ because one person was nit picked and then later someone has discovered a logical flaw 20:23:18 +1 elmiko 20:23:33 rellerreller: but you might disagree with the -1, therefore missing out on bike shed opportunities :) 20:23:56 woodster_ elmiko +1 to mentioning high-priority CRs in this meeting. Usually when a contributor is interested they'll throw a link in the agenda 20:24:00 woodster_ That is true, and I love bike shedding :) 20:24:18 rellerreller: you and me both! 20:24:20 redrobot, alee before changing the number -- i'd like to see us try other solutions (as we are discussing here) 20:24:31 +1 chellygel 20:24:35 chellygel k 20:24:36 perhaps 2 weeks to see if things get better? 20:24:49 I would like to see someone set a date where they are available for fixing. 20:25:01 I just wanted to relay the concerns I heard at the summit. We can table this for a couple of weeks. 20:25:02 rellerreller, for fixing -1's? 20:25:09 I like when person is available for quick turnarounds to make me happy 20:25:18 chellygel yes 20:25:25 redrobot: i was thinking in addition to high-prio stuff, just an agenda item that links to the search url for all open barbican reviews. something that could be brought up quickly and maybe a few could be cherry picked. 20:25:30 chellygel, redrobot - actually I was more concerned about the velocity of the project and not individual reviews per -se 20:25:50 My memory is terrible. If a -1 is not resolved in a day or two then I forget what I reviewed and I get frustrated. 20:26:03 if I look at the last cycle, it seemed like there was a long period of relative inactivity after the summit 20:26:07 alee yeah, I think that's a different agenda item... one that I can probably cover next :) 20:26:24 followed by frantic activity after the mid-cycle 20:26:26 redrobot: i think that's fair too, i mean the folks putting patches up should be on top of posting new patchsets or responding to comments. 20:26:41 #segue 20:27:00 redrobot, its related, because if we fix the turnaround time , maybe the velocity problem will be fixed too. 20:27:13 er, i meant to reply to rellerreller. sorry 20:28:04 I'm ready to move on to the next topic. We'll revisit this topic again in a couple of weeks to see how we're feeling about it. 20:28:14 #topic Mid-Cycle Sprint 20:28:22 redrobot, either way - I think we need to devote part of this meeting to calling out reviews 20:28:28 that have languished 20:28:48 alee agreed, I'll make it a point to talk about those during the meeting. Maybe the last 10 minutes or so. 20:29:05 the mid-cycle sprint has been scheduled 20:29:29 It will be August 5-7 in Laurel, Maryland 20:29:40 I have to run o/ 20:29:44 many thanks to the JHAPL folks for hosting it 20:30:08 one goal that we want for the mid cycle is to land all specs before it happens 20:30:26 one concern that alee mentioned is that last cycle we put off a lot of things because we could "talk about it at the mid-cycle" 20:30:32 that was our goal last cycle :) 20:30:41 because of that, a lot of specs lingered for a while 20:30:54 we wanted the last mid cycle to just be a hackathon as I recall 20:30:54 and we were in a crunch to land code for the last release 20:32:20 so this needs to complete before M3 for any feature?: BP (with API doc verbiage as needed), then doc CR, then server code CR, then client CR? 20:32:43 redrobot, when are the liberty-1, 2 , 3 deadlines? 20:32:51 woodster_, dont forget functional tests 20:33:09 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 20:33:11 ^^ alee 20:33:22 alee: I lumped that in the server CR but better to break it out for sure 20:34:07 I would like to see all BPs landed by liberty-1. It would be ok for some BPs to slip to liberty-2. However, after liberty-2 all pending specs should be punted. 20:34:15 so it seems that the BP and doc CRs should be merged before before the mid cycle to have a hope of meeting M3? 20:34:28 redrobot: got it 20:34:34 redrobot, may I suggest we aim for blueprints/specs to be in by L-1, doc and functional tests by L-2? 20:34:44 alee +1 I like that 20:35:01 (and ideally code too) 20:35:16 so two months 20:35:41 that way we can actually be reviewing code in the midcycle 20:35:54 woodster_ one month to iterate on spec, and one month to iterate on docs/functional tests seems like plenty of time. 20:36:37 I figure it depends on the feature for sure 20:36:41 then hopefully review and/or write code CRs at the mid-cycle. 20:37:51 woodster_, well - non-api related changes dont need functional tests or even docs sometimes .. 20:38:10 alee: that's true 20:38:28 but the advantage of writing the functional tests first for api changes is that you have an agreed upon goal to code to 20:39:08 woodster_, rather than having to scramble at the last minute because what was coded did not match what we were thinking for content types 20:39:12 for inatnce 20:39:45 or that certain scenarios were not actually covered in functional tests 20:40:32 alee: I still think api docs are the very best way to review things...even non-coders can participate in the reviews. Functional/unit tests are nice after that though 20:40:54 woodster_, I'm not saying not to code during the first two months -- just to try to get specs, fucntional tests, api docs done by L-2 20:41:17 woodster_, agreed - you cant write the functional tests without the api docs 20:41:24 alee: that sounds good 20:41:34 otherwise how would someone review them? 20:42:06 (afk -- 2 secs!) 20:42:27 ok, so to summarize: 20:42:39 #agreed We'll aim to land Blueprint Specs by liberty-1 20:42:59 #agreed We'll aim to land Documentation CRs for APIImpact specs by liberty-2 20:43:12 #agreed We will not be landing specs at the mid-cycle 20:43:37 redrobot, doc crs + functional tests please :) 20:44:38 #agreed Functional tests should be submitted with or shortly after the Docs CR 20:45:41 (back) 20:45:59 any comments/questions about the mid-cycle or the milestone goals? 20:46:28 ok, moving on... 20:46:37 #topic CR Reviews 20:47:06 since we're out of topics, let's start the habit of mentioning high priority or long running CRs 20:47:26 I'll start. We really need to land the ACL fixes so we can backport them to Kilo and cut a new release 20:47:30 #link https://review.openstack.org/#/q/owner:%22Arun+Kant%22+status:open,n,z 20:47:47 thanks to arunkant for all the work he's put into these. 20:48:39 redrobot, as you're going to cur a new release with arunkant changes, can you also backport the fix I put in for dogtag? 20:49:24 do we have time for a quick chat about barbican.sh ? 20:49:26 #action redrobot to backport dogtag fix to Kilo branch 20:49:30 redrobot, https://review.openstack.org/#/c/181786/ 20:50:20 redrobot, and agreed - we need to get arunkant changes in -- they've been pending awhile 20:50:41 elmiko sure thing... we have 10 min before the end of meeting 20:50:45 redrobot, which CRs ? there are many? 20:50:54 Will appreciate if folks can review ACl changes there are 3 CRs related ( 1 doc, 2 code CR) 20:51:38 so, i'm helping alee with some packaging issues and i'm curious about the deprecation of barbican-all, and if it would acceptable to create a cli.py module that we could generate some wrapper scripts from? 20:52:02 also, if uwsgi is the "default" deployment option for a single instance/stand alone barbican? 20:52:11 #topic barbican.sh 20:52:53 basically, it makes life very easy for an openstack-barbican package if we can have a script to start the service from, systemd for example. 20:53:10 and i thought barbican-all would be nice, but i'm curious about it's deprecation 20:53:24 elmiko yeah... I think xaeth had some similar concerns for Fedora packaging 20:53:59 uwsgi is not a requirement. just happens to be what Rackspace will be using. I've heard of HP folks successfully running Barbican in Apache 20:54:01 also, i've seen other projects use the setup.cfg to create the script files from python code so that we don't need to carry a bunch of extra scripts. i'm just curious how people feel about this. 20:54:29 i'm fine with uwsgi as it provides a nice stand alone option, apache seems better for integrated options 20:54:31 elmiko I'm on board for moving some scripts into the code tree where it makes sense. 20:54:44 ok, should i create a blueprint/spec or just bug and CR ? 20:55:09 elmiko, I'm ok with bug and cr .. 20:55:16 cool 20:55:17 I think that the RDO and Debian packaging folks would prefer that we support Apache, since I think all of openstack runs on apache out of the box 20:55:31 i'm still experimenting, but i have a feeling i can come up with some clean and straight forward. 20:55:46 redrobot: agreed, and i don't want to change that. 20:55:58 redrobot, interesting -- even barbican -- I may talk to you abiout that - because I'm looking at apache for rdo. 20:56:16 but we do have cases where users might install just the barbican package, and i think a script would be helpful for that. 20:56:45 elmiko agreed. another request that the packagers had was to drop the .py suffix from our scripts 20:57:11 right, using the setup.cfg tools could make it really clean that way 20:57:15 I know xaeth had to do a couple of custom patches for the Fedora package. 20:57:23 (i'm blanking on the package name right now) 20:57:43 setuptools 20:58:07 elmiko yeah, with entry_points that point to a module in the code tree... definitely a nice setup. 20:58:15 right 20:58:35 ok, i'll keep hacking and hopefully throw up a bug/cr sometime in the next 2 weeks 20:58:45 #action elmiko to file bug to move some management scripts from bin/ to entry_points 20:58:52 ok, just about out of time y'all 20:58:54 thanks 20:58:54 thanks for coming! 20:59:10 #endmeeting