Tuesday, 2017-12-19

*** lukebrowning has joined #openstack-tc00:24
*** lukebrowning has quit IRC00:28
*** kumarmn has joined #openstack-tc00:35
*** marst has quit IRC00:35
*** kumarmn has quit IRC00:40
*** diablo_rojo_ has joined #openstack-tc00:47
*** diablo_rojo has quit IRC00:47
*** lukebrowning has joined #openstack-tc01:04
*** lukebrowning has quit IRC01:09
*** lukebrowning has joined #openstack-tc01:10
*** lukebrowning has quit IRC01:15
*** lukebrowning has joined #openstack-tc01:17
*** lukebrowning has quit IRC01:21
*** lukebrowning has joined #openstack-tc01:23
*** zaneb has quit IRC01:27
*** lukebrowning has quit IRC01:28
*** lukebrowning has joined #openstack-tc01:29
*** lukebrowning has quit IRC01:34
*** lukebrowning has joined #openstack-tc01:35
*** lukebrowning has quit IRC01:40
*** lukebrowning has joined #openstack-tc01:42
*** lukebrowning has quit IRC01:46
*** liujiong has joined #openstack-tc01:47
*** lukebrowning has joined #openstack-tc01:48
*** lukebrowning has quit IRC01:53
*** lukebrowning has joined #openstack-tc01:54
*** lukebrowning has quit IRC01:59
*** lukebrowning has joined #openstack-tc02:02
*** lukebrowning has quit IRC02:06
*** lukebrowning has joined #openstack-tc02:08
*** lukebrowning has quit IRC02:13
*** lukebrowning has joined #openstack-tc02:14
*** lukebrowning has quit IRC02:19
*** lukebrowning has joined #openstack-tc02:20
*** lukebrowning has quit IRC02:25
*** lukebrowning has joined #openstack-tc02:27
*** gcb has joined #openstack-tc02:27
*** lukebrowning has quit IRC02:31
*** lukebrowning has joined #openstack-tc02:33
*** lukebrowning has quit IRC02:38
*** lukebrowning has joined #openstack-tc02:39
*** liujiong has quit IRC02:42
*** lukebrowning has quit IRC02:44
*** lukebrowning has joined #openstack-tc02:45
*** liujiong has joined #openstack-tc02:48
*** lukebrowning has quit IRC02:50
*** lukebrowning has joined #openstack-tc02:52
*** liujiong has quit IRC02:54
*** mriedem has quit IRC02:56
*** lukebrowning has quit IRC02:56
*** liujiong has joined #openstack-tc02:56
*** lukebrowning has joined #openstack-tc03:03
*** lukebrowning has quit IRC03:07
*** lukebrowning has joined #openstack-tc03:09
*** lukebrowning has quit IRC03:13
*** lukebrowning has joined #openstack-tc03:19
*** lukebrowning has quit IRC03:25
*** lukebrowning has joined #openstack-tc03:26
*** lukebrowning has quit IRC03:30
*** lukebrowning has joined #openstack-tc03:32
*** lukebrowning has quit IRC03:41
*** lukebrowning has joined #openstack-tc03:42
*** lukebrowning has quit IRC03:47
*** lukebrowning has joined #openstack-tc03:49
*** lukebrowning has quit IRC03:54
*** lukebrowning has joined #openstack-tc03:55
*** lukebrowning has quit IRC04:00
*** lukebrowning has joined #openstack-tc04:03
*** lukebrowning has quit IRC04:08
*** lukebrowning has joined #openstack-tc04:09
*** lukebrowning has quit IRC04:14
*** lukebrowning has joined #openstack-tc04:15
*** lukebrowning has quit IRC04:20
*** lukebrowning has joined #openstack-tc04:21
*** lukebrowning has quit IRC04:26
*** lukebrowning has joined #openstack-tc04:28
*** lukebrowning has quit IRC04:33
*** lukebrowning has joined #openstack-tc04:34
*** lukebrowning has quit IRC04:39
*** lukebrowning has joined #openstack-tc04:40
*** lukebrowning has quit IRC04:45
*** lukebrowning has joined #openstack-tc04:46
*** lukebrowning has quit IRC04:51
*** lukebrowning has joined #openstack-tc04:53
*** gcb has quit IRC04:56
*** lukebrowning has quit IRC04:58
*** gcb has joined #openstack-tc04:58
*** lukebrowning has joined #openstack-tc05:04
*** lukebrowning has quit IRC05:09
*** lukebrowning has joined #openstack-tc05:10
*** lukebrowning has quit IRC05:15
*** lukebrowning has joined #openstack-tc05:16
*** lukebrowning has quit IRC05:21
*** lukebrowning has joined #openstack-tc05:23
*** lukebrowning has quit IRC05:28
*** lukebrowning has joined #openstack-tc05:29
*** lukebrowning has quit IRC05:34
*** lukebrowning has joined #openstack-tc05:35
*** lukebrowning has quit IRC05:40
*** lukebrowning has joined #openstack-tc05:48
*** lukebrowning has quit IRC05:53
*** lukebrowning has joined #openstack-tc05:54
*** lukebrowning has quit IRC05:59
*** lukebrowning has joined #openstack-tc06:04
*** lukebrowning has quit IRC06:09
*** lukebrowning has joined #openstack-tc06:10
*** lukebrowning has quit IRC06:15
*** lukebrowning has joined #openstack-tc06:16
*** lukebrowning has quit IRC06:21
*** lukebrowning has joined #openstack-tc06:24
*** lukebrowning has quit IRC06:29
*** lukebrowning has joined #openstack-tc06:30
*** lukebrowning has quit IRC06:35
*** lukebrowning has joined #openstack-tc06:36
*** lukebrowning has quit IRC06:41
*** lukebrowning has joined #openstack-tc06:43
*** lukebrowning has quit IRC06:48
*** lukebrowning has joined #openstack-tc06:49
*** lukebrowning has quit IRC06:54
*** lukebrowning has joined #openstack-tc06:55
*** lukebrowning has quit IRC07:00
*** kumarmn has joined #openstack-tc07:00
*** lukebrowning has joined #openstack-tc07:04
*** kumarmn has quit IRC07:05
*** lukebrowning has quit IRC07:09
*** lukebrowning has joined #openstack-tc07:10
*** lukebrowning has quit IRC07:15
*** lukebrowning has joined #openstack-tc07:17
*** lukebrowning has quit IRC07:21
*** lukebrowning has joined #openstack-tc07:22
*** lukebrowning has quit IRC07:27
*** lukebrowning has joined #openstack-tc07:32
*** lukebrowning has quit IRC07:36
*** lukebrowning has joined #openstack-tc07:38
*** lukebrowning has quit IRC07:42
*** lukebrowning has joined #openstack-tc07:50
*** lukebrowning has quit IRC07:57
*** lukebrowning has joined #openstack-tc07:59
ttxI'll be late at (or missing) the office hour today due to dentist appointment08:01
*** lukebrowning has quit IRC08:04
*** lukebrowning has joined #openstack-tc08:05
*** lukebrowning has quit IRC08:10
*** lukebrowning has joined #openstack-tc08:11
*** lukebrowning has quit IRC08:16
*** lukebrowning has joined #openstack-tc08:18
*** lukebrowning has quit IRC08:22
*** lukebrowning has joined #openstack-tc08:23
*** lukebrowning has quit IRC08:28
*** lukebrowning has joined #openstack-tc08:33
*** lukebrowning has quit IRC08:38
*** lukebrowning has joined #openstack-tc08:39
*** lukebrowning has quit IRC08:44
*** lukebrowning has joined #openstack-tc08:45
*** lukebrowning has quit IRC08:50
*** lukebrowning has joined #openstack-tc08:52
*** cdent has joined #openstack-tc08:57
*** lukebrowning has quit IRC08:57
*** lukebrowning has joined #openstack-tc08:58
cdenttc-members it's time for office hours09:01
cdentmornin' cmurphy09:01
cmurphymorning cdent09:01
*** lukebrowning has quit IRC09:03
cdentI wonder if we are too in the holiday season for a proper office hours. Seems like we could (re-)digest the cycle length stuff yet more.09:04
*** lukebrowning has joined #openstack-tc09:05
cmurphyhi flaper8709:06
flaper87hello hello! :D09:06
flaper87I actually wanted to bring something up that came to mind from the cycle length discussion09:06
flaper87before I send an email which I think I will anyway but what the heck09:06
* cdent listens09:07
flaper87At some point, in the cycle length discussion it was mentioned that some PTLs didn't feel productive. It was also mentioned that we spend too much time in elections and it was proposed that we should extend the PTL cycle to 1 year if the proposal would have gone through09:08
flaper87but, I'm kinda worried about ppl (continuing to)  misinterpreting the PTL role09:08
flaper87so, I was wondering if we could just do away with it. Rename PTL to PRL (project release liaison), don't do elections but rather let teams decide on their own09:09
flaper87and have ppl volunteer for the job09:09
*** lukebrowning has quit IRC09:09
flaper87That would help easing the pressure for PTLs as far as "being productive" goes because it's not their fault09:10
cmurphywe sort of already do that, the last election there were hardly any actual elections09:10
cdentflaper87: have you looked at the logs from this channel from yesterday? there was some discussion of a related idea09:10
flaper87it's not the PTLs responsibility to make the development cycle productive but rather ease the release process09:10
flaper87cdent: I have not :S09:10
flaper87cmurphy: exactly09:11
flaper87so, why having elections to begin with?09:11
flaper87just let teams figure it out09:11
*** lukebrowning has joined #openstack-tc09:11
flaper87remove the pressure from PTLs09:11
cmurphyto have a process in place in case the teams can't figure it out09:11
flaper87cmurphy: we have a process already: Ppl go to the TC and we deal with the problem09:12
cdentone of the main counters was that only by being ptl are some people able to negotiate with their employers for the time they are able to devote09:12
cdentthat's a fairly common theme for a lot of people who devote a lot of time09:12
flaper87elections take time, ppl need to write proposals which are rarely read when there's only one candidate (or even when there are 2 or more)09:12
cmurphyif there is no team lead and only a release liason then who takes care of these other things https://docs.openstack.org/project-team-guide/ptl.html09:13
cmurphyi mean really those responsibilites should be shared but there kind of needs to be one person monitoring that it's getting done09:13
flaper87the team! Those things are (almost never) done by one person only09:13
flaper87or I guess I've been lucky in the teams I've been part of09:14
*** lukebrowning has quit IRC09:16
flaper87sorry, was re-reading the ptl page09:16
flaper87so, yeah, there are things there that could definitely be shared across the team09:16
cdentflaper87: I'd definitely suggest reading from http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-18.log.html#t2017-12-18T14:28:21 before you post about your idea, at least just to integrate the feedback that was there09:17
flaper87thanks for the link, I was looking for the logs already09:17
*** lukebrowning has joined #openstack-tc09:17
cdentmy main concern was: how does addressing this symptom addressing any of the root problem?09:17
cdentwe seem to be throwing out semi random ideas for how to reshuffle stuff09:18
flaper87lol, funny that ttx mentioned it09:18
flaper87cdent: it's definitely not addressing the root problem, I fully agree with you. But, it *is* a problem in the sense I believe we have grown out of the PTL role09:19
cmurphyalso that yes even though we have an elected PTL those responsibilites should already be shared, removing the official-y part doesn't automatically mean the work gets redistributed09:19
cdentmay it's: in some projects we have grown out of the ptl?09:19
cdenttrying to apply the same solutions to say nova and glance is probably not ideal09:20
flaper87yeah, that's why I said I must have been lucky in the projects I've participated to09:20
cdentflaper87: later in that conversation ttx admitted that he was devil's advocating09:20
flaper87I'm not suggesting that getting rid of it will make sharing responsibilities work but we gotta start somewhere. IF we start by demistifying the role itself,some folks might even feel empowered to step up09:20
flaper87I wish I'd have been around yday09:23
flaper87I agree with ttx that it's prolly better to just wait until next year before bringing this up, though. (not that ppl can't read this channel and do it themselves) but I don't have the energy to deal with another long thread in the next 2 weeks09:24
flaper87sorry if it all felt like a deja vu to both of you, cdent and cmurphy :D09:26
flaper87there he is :D09:26
cmurphyhaha still good to hash it out again :)09:26
cdentI did wonder if maybe I wasn't actually awake yet09:26
cmurphyI wonder how many PTLs are expressing concern about spending so much time on elections09:26
flaper87cdent: lol, that might still be true09:26
cmurphydespite the hardship we still seem to be able to get at least one volunteer from almost every project09:27
* ttx reads backlog09:27
*** lukebrowning has quit IRC09:28
*** lukebrowning has joined #openstack-tc09:29
*** jpich has joined #openstack-tc09:29
ttxyeah, I was looking at low-hanging fruit that we could implement without longer dev cycles, and reflecting back on the discussions we had with K8s people on their model09:30
ttxI think the PTL role (safety valve at project level) is necessary due to our project layout09:31
ttxWe should encourage yet more decentralization, maybe by giving names to the various other components of the role (beyond release liaison)09:31
ttxWe could switch to one election per year, It's a trade-off between election wasting time and the risk of havinog less people step up09:32
cmurphymy other thought is - why try so hard to optimize for the PTLs? the original thread was about part-time developer satisfaction which is a much larger pool of people than the PTLs09:32
ttxIf there was a name for "chairing meetings", maybe more people would step up to fill it09:33
ttxcmurphy: it's also about making it easier for part-time people to achieve leadership positions09:33
flaper87ttx: +!09:33
ttxCurrently the PTL is really not a role for 20% people, even if some manage to do it in smaller projects09:34
flaper87we also have other problems in the community besides part-time contributors09:34
flaper87that thread just triggered some of them09:34
*** lukebrowning has quit IRC09:34
*** lukebrowning has joined #openstack-tc09:35
ttxYou could also have a designated spot for mentoring/first-contact/on-boarding role09:36
ttxCurrently falls on the PTL by default, but in most cases they are not the best person to do it09:37
ttxdue to limited availability and bandwidth09:37
cdentI think we need to be careful when presenting potential solutions. It often leads to people talking about the details of the solution, rather than about the problems it is trying to address. We're culturually predisposed to present solutions, rather than problems (probably because of gerrit :) ) but it means we get easily derailed from solutions.09:37
cmurphycdent: ++09:37
ttxProblem: PTLs have a hard time delegating09:38
cdentthat's a second degree problem, isn't it?09:38
ttxcdent: hmmm, what would be the first degree one? PTLing is too myuch work ?09:39
cdentor at least a biased framing09:39
cdentmaybe? I'm not sure, and that's the point.09:39
ttxcdent: I think the issue with focusing too much on the problem is that you fail to see it's a group of problems09:40
cdentI guess what I'm getting at is that we need to inspect our reality a bit more deeply than we normally do, and question some of our assumption about it.09:40
*** lukebrowning has quit IRC09:40
flaper87I would also add that there seem to be different sympthoms for this problem09:41
ttxLike here, it's a compound of PTLing being a lot of work, part-time contributors having a hard time accessing leadership positions (PTL or core reviewing)09:41
flaper87some ppl just say "they were not able to be productive in a cycle therefore they feel forced to run again"09:41
cdentttx: interesting, I think we fail to get to underlying structural causes, which means the problems will re-rise, slightly modified, nearby09:41
ttxand people natural tendancy to let the person assigned to the job do it09:41
*** lukebrowning has joined #openstack-tc09:42
ttxcdent: sure, but if the analysis is too narrow, then you fix underlying cause A, but make everythign else worse09:42
cdentof course, which is why I'm intentionally using the term "structural" but perhaps "foundational" would be more expressive09:43
cdentre letting the person assigned to the job do it? How much of it is that, and how much of it is simply that other people are sane enough to not take on more work? For example:09:43
cdentif you're a nova dev you might see that matt is too busy, but you yourself are already months behind on your task list for thing you need to change in nova09:44
ttxcdent: that's what I meant I think09:44
ttxconvenience of the default09:44
ttx(I porrly phrased it)09:44
ttxpoorly even09:44
flaper87which doesn't necessarily means the default will always take things on. Ppls culture and will to do things also comes into play. One day Matt might just flip tables, break windows and leave and that's what I would also like to avoid09:45
cdentwe are currently structured, and have a backlog that requires, at least in some projects, greater than full time work09:45
ttxcdent: I don't think it's structural09:45
cdentthe people who are doing that full time work are only able to do it by being highly visible and strongly associated with important roles09:46
ttxIt's expectations that we set ourselves09:46
flaper87Those expectations do have a history and most of them were real in the past09:46
*** lukebrowning has quit IRC09:46
ttxflaper87: sure, if you are assigned full time on a project, you need to do some visible work09:47
flaper87I think we have some good examples that we can do away with some of them09:47
ttxsince it's hard to justify the time you spend there otherwise09:47
flaper87ttx: yup (I'm agreeing with you, fwiw :D)09:47
ttxin terms of organization's KPI09:47
ttxI'm not disagreeing with cdent :) I just want to turn that into something actionable rather than just another reason to do nothing about it09:48
*** lukebrowning has joined #openstack-tc09:48
flaper87as I said earlier, I don't thing the PTL issue is the root cause but it does seem to be a problem that has been mentioned a couple of times and that I've encountered throughout my years in the community09:49
flaper87the role is often misunderstood because of the reality of some projects09:49
cdentthe role is much diffrent between projects09:49
cdentwe can't apply a single fix09:50
ttxIf I had to zero in a foundational cause, I suspec tthat would be the traditional misalignment between open source contributors at various organizations and their company behavior/mode of operation/ performance metrics/baseline.09:51
flaper87cdent: and yet it shouldn't if we all follow a single set of expectations09:51
ttxBut frankly, there is little we can do to fix that09:51
flaper87it is but it shouldn't so, at some point ppl started assuming more or fewer things09:51
flaper87some may be acting based on tribal knowledge ?09:51
cdentflaper87: culture jamming to get everyone on the same expectation page would be a huge undertaking09:52
*** lukebrowning has quit IRC09:53
*** liujiong has quit IRC09:53
flaper87I'm not saying we should just do culture jaming but revisit the set of principles by which we are acting. We do have them, we've documented them.09:53
cdentand I'm not sure that getting everyone following the same set of expectations is even healthy09:53
ttxThere is a reason more and more of our contributors end up at Red Hat -- it's an org that has clarified their stance with respect to open source better than most09:53
ttx(and is successful with it)09:53
flaper87It's the set responsibilities that I would like to change.09:54
*** lukebrowning has joined #openstack-tc09:54
ttxBut I think there is little we can do to influence other megacorporations. A number of people were hired into them with a clear mandate to fix them and failed09:55
ttxIf you can't fix it with an internal mandate, I don't think an external body of people with no mandate or influence can09:56
ttxSo I prefer to focus on second-order problems that we could actually fix09:56
cdentwe could just down tools for a while, go on strike :)09:57
ttxrather than say " all our problems are probably due to capitalism "09:57
cdentall our problems are probably due to capitalism09:57
ttxCouldn't we blame the situation on a combination of Trump and Brexit ?09:58
ttxthat would work09:58
cdentTrump and Brexit are probably due to capitalism09:59
ttxdamn, root cause again09:59
*** lukebrowning has quit IRC09:59
ttxok, I should update the TC tracker09:59
ttxand process governance reviews10:00
cdentSo before we leave capitalism, I continue to feel like we are insufficiently agressive with contributing corps about their responsibilities. Is that because I'm missing it happening somewhere, or that it happened in the past and so now it isn't happening again, or that it's not done because it's not the done thing?10:00
ttxcdent: I'm pushing to get a paragraph describing their community contributions on this year report10:01
cdent(Once I get past these questions I can move on to second-order stuff at least feeling a bit more informed.)10:01
ttxI have hopes that it will make teh situation better10:01
ttxnot fix it, but incrementally better10:02
cdentThat's the shame and carrot mode of encouraging contribution. What examples are there of asking or demanding?10:03
ttxcdent: we did that at Board+TC+UC meetings, presenting the list and all10:03
ttxThe forming of the List is one of those aggressive asks10:03
ttxWe need to promote the list a bit more10:04
ttxThe goal of it was so that we could focus on the same asks10:04
ttxrather than spread the energy around10:04
*** lukebrowning has joined #openstack-tc10:05
ttxso yeah, explicit ask using the List on one side, and accounting / promoting good behavior with the report10:05
ttxon the other10:05
cdentyou mean the most wanted list?10:05
ttx"Help most needed" ?10:05
ttxHappy to take other suggestions. Those are very 2017 now10:06
cdentI like that list but it is very very far from being a demand for general boots on the ground style resources.10:07
ttxhow do you propose we demand general boots on the ground style resources ?10:07
cdentIf this were the military we don't just need advisors, we also need infrantry, lots and lots of infrantry10:07
cdentI don't know! I'm asking if it has ever been asked for. I'm trying to get some historical context.10:08
ttxhmm, I'd say you need more supply line people (technical debt) than infantry (feature)10:08
cdentmetaphor failure :)10:08
ttxI see what you mean10:09
ttxless specialists, more generally-useful people10:09
*** lukebrowning has quit IRC10:09
cdentSo the question remains, since I lack some of the history: have we, or how often have we, asked for that?10:11
cdentand if the answer is no, is there a clear reason for why not?10:11
ttxI think we did, before the list was there. Actually the list is the result of the board asking back: "where exactly do you need resources"10:12
ttxBasically the ask was too vague10:12
ttxand that was used as a way to not answer it10:12
ttxwhich is why we got more specific10:12
ttxThe List is also something that can be relayed effectively10:12
ttxFor example Huawei said they would promote it in other Chinese orgs10:13
cdent(Tangent, noted for sake of memory, maybe we need to flip the query some of the time: What would you like us to do less of?)10:13
ttxflaper87: would you concur that we did ask, but the ask lacked clarity?10:13
ttxgrr sphinx10:19
ttxall my approved changes will fail due to some external issue10:21
cmurphyttx: did you see http://lists.openstack.org/pipermail/openstack-dev/2017-December/125710.html ?10:23
ttxcmurphy: not read it yet, but saw some patch on the releases repo to fix it there, so was expecting it10:23
ttxhmm not sure that's exactly the same though10:25
flaper87sorry, had a call to attend10:25
ttxwith open(filename, 'r', encoding='utf-8') as f:10:25
ttx2017-12-18 16:06:19.354021 | ubuntu-xenial | TypeError: 'encoding' is an invalid keyword argument for this function10:25
ttxlooks more like the issue we had in releases10:26
flaper87ttx: yes, I concur :D10:26
ttxok, tracker updated.... now looking into the doc build issue10:29
*** lukebrowning has joined #openstack-tc10:29
ttxI should catch up with email first probably10:29
cdentall our problems are probably due to email^wcapitalism10:33
*** lukebrowning has quit IRC10:34
*** lukebrowning has joined #openstack-tc10:36
*** jpich has quit IRC10:40
*** lukebrowning has quit IRC10:41
openstackgerritThierry Carrez proposed openstack/governance master: Use io.open instead of open in extensions  https://review.openstack.org/52902510:41
ttxLet's see if that flies better10:41
*** lukebrowning has joined #openstack-tc10:42
*** lukebrowning has quit IRC10:47
*** lukebrowning has joined #openstack-tc10:48
*** lukebrowning has quit IRC10:53
*** lukebrowning has joined #openstack-tc10:55
*** lukebrowning has quit IRC10:59
ttxIt does not, I blame mordred11:05
*** lukebrowning has joined #openstack-tc11:05
ttx(for dragging us back into py2.7)11:05
*** lukebrowning has quit IRC11:10
*** lukebrowning has joined #openstack-tc11:11
*** lukebrowning has quit IRC11:17
*** lukebrowning has joined #openstack-tc11:39
*** lukebrowning has quit IRC11:43
*** lukebrowning has joined #openstack-tc11:45
*** lukebrowning has quit IRC11:50
*** lukebrowning has joined #openstack-tc11:51
*** lukebrowning has quit IRC11:56
*** lukebrowning has joined #openstack-tc11:58
*** lukebrowning has quit IRC12:03
*** lukebrowning has joined #openstack-tc12:06
*** lukebrowning has quit IRC12:15
*** lukebrowning has joined #openstack-tc13:13
*** lukebrowning has quit IRC13:18
*** lukebrowning has joined #openstack-tc13:20
*** lukebrowning has quit IRC13:24
*** lukebrowning has joined #openstack-tc13:26
*** lukebrowning has quit IRC13:31
*** lukebrowning has joined #openstack-tc13:32
fungii still think people have the cause and effect reversed for overworked ptls. at least from what i've seen people end up as ptl for perpetually volunteering to take responsibility for more and more things, not the other way around13:35
fungiwhen i was ptl i constantly attempted to delegate tasks by asking for volunteers13:35
fungiultimately, most of the time it's the same already-overloaded people who volunteer to help13:36
fungimost of whom are former ptls, and the rest are potential future ptls13:37
*** lukebrowning has quit IRC13:37
persiaSuch a model is also an excellent way to create the future PTLs that may be needed.13:37
fungibut the idea that if you just get rid of the ptl the teams will more evenly spread responsibilities? doesn't match the behavior patterns i've witnessed13:38
*** lukebrowning has joined #openstack-tc13:39
persiaOn the other hand, it might help with the employment issue: if employers only allow folk to spend time on projects if they are PTL, then abolishing PTL is a good way to break that behaviour.13:39
persiaIn my experience the PTL is often the person with the *least* time available for code and review.13:39
fungiagreed, they'll stop having to allow any folk to spend time on projects once no one person is the designated point of contact13:40
persiaUm, no.13:40
persiaThe idea that employers allow folk to spend time on projects because of the roles is the wrong end of the stick.13:40
fungiit's unclear that by taking away a reason for employers to fund individuals will result in them funding more individuals13:41
persiaEmployers should be assigning folk to spend time on proejcts where those projects are of benefit to the employer.13:41
persiaHaving roles is one way to gamify this, so that employers can compete on roles, as well as by other metrics.13:41
cdentfungi, yeah, it is the perpetual volunteers who continue to perpectually volunteer13:42
persiaI don't understand why "I'm PTL" is justification for employment.  Is it extortion, in that it means "if you don't let me spend time on $project, you'll get bad press because you let it fail"?13:42
fungiahh, i see, the suggestion is by further flattening organization we take away distracting details for them to fixate on, and increase the chances that they fixate on the details we want them to13:42
persiafungi: I think of it as "fixate on details that matter to them to the ultimate success of the project", but yes.13:43
*** lukebrowning has quit IRC13:43
cmurphythat seems a little convoluted to me13:44
cmurphyit's immpossible to guess what any given employer will fixate on13:44
cmurphymy employer for instance would not play into any gamification of roles13:44
*** lukebrowning has joined #openstack-tc13:44
fungiin the past at least the high-profile incidents have mostly been where employers competed on easily-measured metrics (number of people in leadership roles, number of commits merged, whatever) in an effort to show their customers they're involved in the project and have people who understand it rather than simply reselling it13:45
persiacmurphy: No?  Has your employer never touted the number of TC members, PTLs, or similar it employs?13:45
cdentI think there's another factor here, which is not related to companies bragging, but employees making negotiations, explicity and implicit, with their employers over time management13:46
cmurphypersia: I suppose we've touted our board chair but historically we've had relatively few tc members and ptls employed13:46
cdentall three of my openstack employers have required quite a lot of finessing to allow me to do what I do13:46
persiaI agree that it is impossible to guess what any given employer may choose to fixate upon, but I suggest we can ask the Board, and maybe a couple high-profile non-represented employers what they want to achieve, and provide them tools to do so.13:46
cdentI think we're making a large assumption about the amount of explicit decision making is happening by individuals and companies13:47
persiacdent: Every one who has ever paid me has required a fair amount of finessing if I wanted to convince them to let me be me, rather than being a fungible unit performing an automatable action: I don't think that is unique to openstack (or open source), nor something that this community can solve (although members of this community may be part of another commuity dedicated to solving that issue).13:48
persiaMy observation is that there is little explicit decision making, and almost zero communication between most developers assigned to openstack and most organisations openstack-related strategy groups.  I believe this is horridly broken, and that fixing that is of greater utility than trying to help people game employment by providing mechanisms for people to not take direction.13:49
*** lukebrowning has quit IRC13:50
cdentpersia: sure, but that means that the interactions are individual and independent of our guesses about patterns13:50
persiaThat said, I recognise that with the current individuals and organisations we have involved, it may be easier to do it the other way.13:50
persiacdent: Yes.13:50
cdent(that sure was on the first point, I agree on the second point, but I'm not sure how to make that so)13:50
*** lukebrowning has joined #openstack-tc13:51
persia(yes was to sure)13:51
cdentso yeah, we need a higher fidelity feedback loop (both^wmultiple directions)13:52
*** lukebrowning has quit IRC13:55
cdentthat fidelity loop is where I wonder if the TC is not using as much leverage as they could at/with the board. I tend to think of us a representatives who ought to be curating the feedback loop.13:57
*** lukebrowning has joined #openstack-tc13:57
*** mriedem has joined #openstack-tc13:58
persiacdent: We can help, and representatives of TC and Board have tried before.  In practice, until participating organisations are willing to collaborate at a strategic level (sharing plans, etc.), it becomes hard to make much progress.13:59
persiaA past example of the attemot was to suggest employer's product managers all gather, and plan future cycles, which worked for one cycle, until it turned out the internal feedback wasn't working, so that the agreements made at those meetings didn't translate to instructoins to engineers.14:01
persiaA future attempt probably needs a different way of making a business case for such strategic collaboration.14:01
*** lukebrowning has quit IRC14:01
dtroyerSo consider that another break in the feedback loop is that the (appointed via platinum/gold membership) board members are often relatively high in an organization and sometimes totally divorced from resource- or even project-level decisions.  There maybe at least one or two more layers that need to be bridged internally to get back to those directly involved in the community14:03
persiadtroyer: I believe that is the break that caused the collapse to which I alluded: thank you for the clear description of the underlying org-internal issue (there also remain openstack-internal issues, but many of those that applied then do not apply now (fewer "celebrity" developers arguing against host orgs))14:05
* fungi feels like "celebrity developer" sound a lot like "celebrity plumber"14:14
fungier, sounds. i need to move to a room with a better keyboard14:15
*** lukebrowning has joined #openstack-tc14:17
dtroyerfungi: who of us is This Old House's Rich Trethewey?14:18
*** lukebrowning has quit IRC14:22
*** lukebrowning has joined #openstack-tc14:23
persiafungi: To restate: in the early years, I felt we had a fair few developers who had a clear vision for openstack, which they pursued entirely independent (and sometimes in opposition to) employer opinion.  I don't feel like there is as much of that now: my impression is that a significantly larger percentage of openstack developers are assigned to work on openstack because it is the right thing for the employer, rather than because someone sold "14:25
persiathat openstack thing" as a mechanism to consume OCTO budget.  Some of those folk seemed to change employers every cycle, with an attitude of "I'm doing X, if you won't pay me, I'll find someone who will".  While there is still a fair bit of turnover, and some of it is about different orgs paying for specific activities, more seems focused on functionality than personality these days.14:25
smcginnisfungi: ++ "people end up as ptl for perpetually volunteering to take responsibilities"14:25
*** lukebrowning has quit IRC14:28
*** lukebrowning has joined #openstack-tc14:30
*** kumarmn has joined #openstack-tc14:30
*** lukebrowning has quit IRC14:34
smcginnisAnother thing that's come to mind with all the discussions lately - I am a bit concerned about the constant "not-directly-obvious-or-useful" changes.14:34
*** lukebrowning has joined #openstack-tc14:36
smcginnisAfter let's change cycle timing, let's get rid of midcycles and have PTGs, let's get rid of PTG's and have midcycles, let's rename the PTL, let's not have a PTL, let's change how all our jobs are run, etc, I wonder how much more until folks starting deciding - "screw it, I can't keep up with all these changes" and leaving.14:36
*** lukebrowning has quit IRC14:41
*** lukebrowning has joined #openstack-tc14:42
cdentsmcginnis: I agree that the changes, if there's little perceived value, are an incentive to leave. But on the other hand, at least some people think _something_ has to change. For me that's an argument to change things substantially so the value is more apparent, but I have yet to think of a reasonable change.14:43
smcginniscdent: No, I completely agree something probably has to change.14:43
smcginniscdent: I'm just worried if we start making changes here and there without really thinking it through and trying to focus on a specific problem, it will be perceived as just churn with little value.14:44
smcginnisSo I am for change, just think we need to not rush in to anything.14:44
* cdent nods14:45
dtroyerI know that ttx has been doing some "devil's advocating" but I worry that the image of looking at changing to be more like the current hype-child gives the wrong impression.  I know my gut reaction is to automatically push back on anything that smells like "let's be like them over there", whomever "them" might be.14:45
cmurphyI think any change has to start out as a thought experiment before it forms into an actionable valuable change14:46
mugsieas a data point, for my employer[-2], during the massive reshuffles, the only reason I kept any upstream time at all was I was a PTL. The only reason employer[-1] let me go to ATL, and paid for BOS was I was a PTL.14:47
*** lukebrowning has quit IRC14:47
mugsieand a major part of the reason I am where I am now is due to being PTL14:48
mugsieit *is* a thing to organisations, no matter how much we wish it wasn't14:48
persiaIndeed, role gamification is working.  On the other hand, in Denver I spent some time with someone who was in a position where, if they didn't manage to get a new project started (so they could be PTL), they would be let go.  Thankfully, they were able to secure alternate employment, but there is surely something that could be done to messaging to reduce that sort of thing.14:50
cdentOne thought that crossed my mind through all this, one that I don't care for because of past positions, is that we should vastly deouple each project from one another, including in terms of release cycles. What works for nova will not work for designate and vice versa (replace with any two projects).14:52
mugsiepersia: sure - part of the reason kosmos died was we could not get into the bug tent - so I get the problem14:52
mugsiecdent: yeah - that is very true14:53
persiacdent: A counterargument that is popular in "safety critical" circles is that the combinatorial problem of deploying a set of features such that all components are mutually intercompatible is a very hard one.14:53
cdentAs for "I completely agree something probably has to change." we all seem to have some form of agreement on that but I don't think I've heard much of a consensus on why we need to change.14:53
* cdent nods at persia14:54
persiaNo insoluable, but I think all the projects need a bit more focus on working well with different versions, and we'd need massively more test resources to make that reasonable.14:54
mugsieor, decouple some of the "core"14:54
mugsiea lot of the other projects work quite well across mixed versions14:54
*** lukebrowning has joined #openstack-tc14:55
persiacdent: I think there is consensus that change is needed because 1) things seem to be moving more slowly, and 2) a larger portion of people are frustated.  I don't think either of these has a single root cause, and that the desire for change comes from conflation of many symptoms.14:55
persiaBoth of these are complicated as the entire polity is also experiencing some concern about employment (and concern that, as individuals, they may not be able to participate in the polity without funding changes, out of their control, so seek structure changes, within their control)14:56
cdentpersia: yeah, but I'm not even sure how much of various causes for frustration I've seen enumerated in an aggregate fashion. It's more of lurking fear.14:57
persiaI have only encountered FUD: nothing concrete.  I can also say that the orgs with which I've been discussing things over the past six months are all telling me they are actively committed to long-term engagement with OpenStack, which is a different message than I hear from folk employed to work on OpenStack (even those associated with organisations for which I have alternate communicatons channels).14:58
ttxNot totally unrelated -- I'm looking for suggestions on how to put The List (help most needed) in front of more eyes14:59
ttxso if you have ideas, let me know14:59
*** lukebrowning has quit IRC14:59
dtroyerttx: include it in the annual report with the paragraphs provided by member companies.  over time those can be cross-referenced15:00
ttxMy current plan involves continuing to formally presenting it at Board+TC things, engage privately from the Foundation, write a blogpost paraphrasing the entries15:00
cdentttx: relatively simple, but those of who are employed by contributing companies should probably make some effort to spread it internally to whoever seems right.15:00
ttx++ to both15:01
cdentany maybe a more widespread "give this to your manager" push15:01
*** zaneb has joined #openstack-tc15:01
*** lukebrowning has joined #openstack-tc15:01
* ttx jumps on a meeting15:01
*** lukebrowning has quit IRC15:06
*** lukebrowning has joined #openstack-tc15:08
*** marst has joined #openstack-tc15:10
*** lukebrowning has quit IRC15:12
fungito some extent i blame our reliance on integration testing for the perception that core services are so tightly coupled. mriedem seemed pretty confident you could mix-n-match nova with a variety of versions of cinder, keystone, neutron, glance, et cetera... but we only test one combination of versions together due to the combinatorial effect of test matrices15:14
*** lukebrowning has joined #openstack-tc15:14
mriedemexcept n-cpu -115:14
mriedemif there is a reason that you can't run mixed versions of nova/cinder/neutron/glance/keystone, at least n-1,15:15
mriedemi'd like someone to tell me15:15
mriedemrather than hand wave it's not possible15:15
mriedembecause as far as i know it's all rest api stuff15:15
fungiwell, thinking more n-m/n+o version combinations15:15
mriedemsure, but still,15:16
fungiif it already works one version back/forward then if we go to interim release models the idea still holds15:16
mriedemi don't know how many times i've said, "we can't assume cinder has this because rax is running icehouse still"15:16
mriedem*icehouse version cinder15:16
mriedemwith the random dict of craziness that is the neuron port binding profile, i know things can get tricky depending on your neutron vendor backend, which is why we've talked about doing vif negotation with os-vif for a long time15:18
fungiwhile i think our mantra of "if it's not tested it's broken" is a good reminder to strive for better test coverage, we can't ever hope to try every combination of config options or service and library versions someone might deploy in the wild, and i expect various teams still attempt to treat bugs exposed under those sorts of conditions as actual bugs to be fixed15:18
mriedemfungi: i would certainly treat those as bugs15:19
*** lukebrowning has quit IRC15:19
mriedemif nova doesn't work with older versions of the other services, i'd consider that a bug15:19
fungiso to imply that we only "support" a specific blessed and frozen cross-section of versions and options corresponding with what we test in ci is doing somewhat of a disservice to the developers and end users15:19
mriedemwe do have some special cases, like the ironic driver,15:19
mriedemthat has a hard minimum requirement on ironic api being at some version each release15:20
mriedemthat's really no different than the libvirt driver saying it requires a minimum version of libvirt each release15:20
*** lukebrowning has joined #openstack-tc15:20
mriedemor vcenter, etc15:20
cdentfungi: do you agree or disagree that releasing in lockstep with each other enhances the perception that you have to use in lockstep?15:23
mriedemyou didn't ask me, but i think it enhances that perception15:24
fungii agree that we put a strong emphasis on the set of versions we test and it leads to people thinking the openstack core services are more tightly-coupled than they actually are15:24
mriedemespecially when each distro releases the coordinated release as a whole and announces it at the summit for marketing15:24
fungii don't know whether the release timing and propaganda plays into it, but i expect it might15:24
mriedemvendor x releases pike!15:24
mriedemnot, vendor x releases cinder version 1, nova version 2, glance version 3, etc etc15:25
cdentmriedem: I didn't ask you because I kind of assumed your answer, but more than that was responding to a particular statement fungi made. Your answer, of course, is very welcome.15:25
*** lukebrowning has quit IRC15:25
mriedemremember when we have 2012.x releases for all projects? :)15:25
cdentI really think it should be okay for some projects to not release, simply because not much happened, or all they did was bug fixes15:25
fungii'm thinking more about the perception from within our development community that the services are so tightly-coupled from a versioning perspective. until our developers are disabused of that notion, we can't expect the general public to believe it15:26
cdentfungi: right, I'm asserting we build that in by having us all working to the same schedule15:26
cdents/asserting/wondering if/15:26
fungientirely possible15:26
*** lukebrowning has joined #openstack-tc15:26
fungiit's okay to assert things you're wondering and then see if you encounter an assertion failure ;)15:27
cdentit is with _you_, that's not always the case with other folk...15:27
mriedemi think i've only heard of two people say the core services are tightly coupled in the context of the 1 year cycle thread, and that's dean and graham, but i haven't heard specific examples of why they think they are so tightly coupled15:27
cdentI keep learning that the hard way over and over and over (which I guess means I'm not learning)15:27
cdentmriedem: I think they mean they are built that way, not that they operate that way15:28
mriedemwhat does built that way mean?15:28
dtroyermriedem: I'll admit to my knowledge being out-of-date, it was more along the upgrade order that I still think an an issue there, and again, probably more ignorance than experience15:28
mriedemone should probably expect that nova gets upgraded after keystone/glance/cinder/neutron,15:29
mriedembecause nova depends on those other projects15:29
dtroyerupgrade order -> required a before b and lock-step that may be specific to particular releases15:29
mriedemi think since at least kilo that is less of an issue15:30
mriedemthe ordering i mean15:30
mriedembecause kilo was microversions15:30
cdentmriedem: by "built that way" I mean what I was saying above: we work (build) together in lockstep15:31
mriedembefore that, sure there were lots of changes where cinder/nova had api changes (swap volume, guest-assisted snapshot) where you'd have to upgrade them together for things to work15:31
dtroyerif we were to do away with the coordinated release we would need to maintain a matrix of version compatibility (at least going forward) but it appears that we already may be in that situation and would be beneficial to our users to publish such a thing.15:31
*** lukebrowning has quit IRC15:32
mriedemso a gate job where everything gets upgraded except nova maybe?15:32
fungiyeah, it does sound like we have a lot of loose/flexible version compatibility and by focusing on the specific combination we test we give the impression that's not the case at all15:32
*** lukebrowning has joined #openstack-tc15:33
mriedemat this point, i would need the ops and UC communities to come forward and tell us, "yes 90% of us upgrade *this way* and you don't have a scenario for that in your CI"15:33
dtroyerI've been hoping that things like the ff-upgrade efforts might produce at least some of those jobs.  Maybe I've got it backward?  Build the jobs and they will come?15:33
mriedemotherwise it's all conjecture15:33
dtroyermriedem: ++ FWIW, my notions of upgrade order/requirements came from someone's upgrade experience (wish I could remember who)15:34
mriedemi don't know who is leading the FFU (or LTS) efforts15:34
fungiit's a little bit of a straw-man concern on my part though. i'll also posit that as much as people claim tight coupling between versions is a hindrance to adoption, users/deployers of the software also look to us to tell them which versions to ship/run together15:34
mriedembtw, can i say it's a luxury that we even have upgrade testing *at all*?15:35
fungiso if we dropped the coordinated release and teh recommendations of tested version combinations, we'd get new complaints that everyone's lost in the wilderness of missing recommendations15:35
mriedemfungi: sounds like constellations15:35
fungii think constellations are meant more to cover combinations of services for specific use cases rather than combinations of versions15:36
fungibut since we don't have them yet, it's hard to say what they are ;)15:36
mriedemsure, but this is the version matrix constellation/black hole15:36
cdentif we _did_ have constellations then they would provide a space within which to explore version flexibility15:37
dtroyerconstellations (as I understand them) are layered on top of the projects, the version matrix would be necessary (and the same) with or without them15:37
mriedemi didn't mean to segue into constellations by any means15:38
*** lukebrowning has quit IRC15:38
dtroyerseeing as how the version compatibility is a hard technical thing, constellations are a soft marketing thing15:38
mriedembut if the majority of our users think that a CI job where you upgrade everything except nova would be good to have, that would be good feedback15:38
fungirelated: it seems like dropping the weekly irc meeting in favor of office hours has given us one giant week-long irc meeting ;)15:38
dtroyerfungi: but it flows a lot slower15:39
mriedemis this office hours time?15:39
mriedemif it is, what was yesterday?15:39
smcginnismriedem: It's office day today apparently.15:39
fungiit was ~6.5 hours ago15:39
fungiand is continuing, apparently ;)15:39
mriedemthe -tc channel is now my new favorite place to not get anything done15:39
funginext office hour technically starts at 01:00 utc tomorrow, so another ~9 hours and change15:40
cdentnot to be a total prig, mriedem, because I know you were making a joke, but it is because we probably don't have these kinds of broadly ranging conversations quite enough that we end up in these situations15:40
fungii completely agree. i think this is great as long as we parlay it into some outcome15:41
mriedemi was mostly joking yes, sorry, i should have added the obligatory smiley emoticon,15:41
mriedembut it would be useful if some kind of action item came out of this,15:41
mriedemso should i ask in the ML if people want an n-1 (nova) CI job?15:42
persiaI actually find this channel to be a lot like a small office.  At certain times, folk promise that they will try to be here (if schedule allows), and other times folk are working in a way such that anything happening here may be able to distract them: when it isn't office hours folk are welcome to walk away with their laptop to avoid the noise, but discussions continue.15:42
cdentmriedem I was just using you as a convenient fulcrum, I'll send you a cheque15:42
mriedempersia: yeah - definitely reminds me of the "collaboration rooms" at my previous employer15:42
cdenton the n-1 ci job, seems like a good idea15:43
mriedemif someone wants me to try and formulate into a ML post about mixed version CI and start that thread, i'm willing15:43
* fungi ran private internal irc servers at several previous places of employment. always worked out extremely well for coordinating things15:43
cdent(i mean the email()15:43
mriedemok i can shoot that out there15:43
*** lukebrowning has joined #openstack-tc15:44
fungias an alternative, even just a thread or blog post or superuser article about how the so-called "core" services aren't as much of a tightly-integrated tangle of twine as lots of people seem to assume15:44
fungialso curious, on the suggested ci job, how does that differ from the partial upgrade job nova already has? the existing one tests different versions of nova's control plane and compute node together?15:46
mriedemfungi: yes, latter - grenade upgrades nova control plane to n and leaves n-cpu at n-115:46
fungiand the proposed thing would have grenade upgrading nova control plane and n-cpu to n and leave the other openstack services at n-1?15:47
mriedemno, opposite15:47
fungiahh, hold all nova at n-1 and upgrade everything else15:47
mriedemupgrade everything except nova to n, leave all of nova at n-115:47
fungithat seems like a job we'd get more benefit from running on !=nova15:47
mriedembecause nova depends on the other services, and nova is presumably harder / slower to upgrade because you roll across the computes15:48
mriedemfungi: you mean integrated gate?15:48
mriedemno, i see what you mean15:48
*** lukebrowning has quit IRC15:48
mriedemrun it on all jobs except nova15:48
fungiwell, it would only make sense on master branch changes for non-nova services or on stable branch changes for nova15:49
mriedemsince you wouldn't test the change in nova under review anyway15:49
funginova itself doesn't have a lot of control over whether other services do things to make themselves incompatible with previous nova releases15:49
mtreinishmriedem: the multinode job also holds cinder vol (and bak I think) at n-1 on the subnode15:49
mtreinishor I think that change landed15:50
*** lukebrowning has joined #openstack-tc15:50
fungibut as far as outcomes, i was really thinking more along the lines of finding ways to emphasize that even though we test upstream that certain versions of things work together, those aren't the only combinations we expect to work and people who want to consider running with other combinations should feel free to (test those themselves of course but) expect that too15:52
fungiand report bugs if they find those expectations are really not holding true15:52
fungithere are plenty of large projects out there, critical to daily infrastructure at some very large organizations even, with little or no automated testing at all. we're giving a false impression by suggesting only what we test is what will work15:54
cdentOne of the phrases that leaked into my head when I first started in openstack was "tyranny of the gate", the meaning of which captured a lot of what you're saying there15:54
fungithe fact that we have far more thorough testing than most other free software projects is great, but sometimes it can paint an inaccurate picture15:55
*** lukebrowning has quit IRC15:55
*** lukebrowning has joined #openstack-tc15:56
mriedemthread started15:59
*** lukebrowning has quit IRC16:01
*** lukebrowning has joined #openstack-tc16:02
*** lukebrowning has quit IRC16:07
*** lukebrowning has joined #openstack-tc16:09
*** lukebrowning has quit IRC16:13
mnaseri think the onus is on services that consume nova to test against different versions16:14
mnaserespecially with micro versions being a thing in nova.. i think its fair to say "this feature requires microversion x which onles come with y release of nova"16:14
*** lukebrowning has joined #openstack-tc16:15
*** lukebrowning has quit IRC16:20
*** lukebrowning has joined #openstack-tc16:21
*** lukebrowning has quit IRC16:26
*** lukebrowning has joined #openstack-tc16:28
*** lukebrowning has quit IRC16:32
*** lukebrowning has joined #openstack-tc16:34
*** lukebrowning has quit IRC16:39
*** lukebrowning has joined #openstack-tc16:48
*** lukebrowning has quit IRC16:52
*** lukebrowning has joined #openstack-tc16:54
*** lukebrowning has quit IRC16:59
*** lukebrowning has joined #openstack-tc17:34
*** lukebrowning has quit IRC17:39
*** lukebrowning has joined #openstack-tc17:45
*** lukebrowning has quit IRC17:50
*** lukebrowning has joined #openstack-tc17:52
*** lukebrowning has quit IRC17:56
*** lukebrowning has joined #openstack-tc17:58
*** lukebrowning has quit IRC18:03
*** lukebrowning has joined #openstack-tc18:09
*** lukebrowning has quit IRC18:14
*** harlowja has joined #openstack-tc18:15
*** lukebrowning has joined #openstack-tc18:15
*** lukebrowning has quit IRC18:20
*** lukebrowning has joined #openstack-tc18:31
*** lukebrowning has quit IRC18:36
*** lukebrowning has joined #openstack-tc18:37
*** lukebrowning has quit IRC18:42
*** lukebrowning has joined #openstack-tc18:44
*** lukebrowning has quit IRC18:48
*** lukebrowning has joined #openstack-tc18:50
*** lukebrowning has quit IRC18:55
*** dtantsur is now known as dtantsur|afk18:56
*** lukebrowning has joined #openstack-tc18:56
*** cdent has quit IRC18:56
*** lukebrowning has quit IRC19:01
*** lukebrowning has joined #openstack-tc19:05
*** lukebrowning has quit IRC19:10
*** lukebrowning has joined #openstack-tc19:11
*** lukebrowning has quit IRC19:16
*** lukebrowning has joined #openstack-tc19:18
*** kumarmn has quit IRC19:21
*** lukebrowning has quit IRC19:23
*** lukebrowning has joined #openstack-tc19:24
*** lukebrowning has quit IRC19:29
*** lukebrowning has joined #openstack-tc19:31
*** lukebrowning has quit IRC19:36
*** lukebrowning has joined #openstack-tc19:37
*** openstack has joined #openstack-tc19:43
*** ChanServ sets mode: +o openstack19:43
*** tdasilva has quit IRC19:47
*** tdasilva has joined #openstack-tc19:47
*** lukebrowning has joined #openstack-tc20:00
*** lukebrowning has quit IRC20:05
*** lukebrowning has joined #openstack-tc20:14
*** lukebrowning has quit IRC20:19
*** lukebrowning has joined #openstack-tc20:30
*** lukebrowning has quit IRC20:34
*** lukebrowning has joined #openstack-tc20:36
*** kumarmn has joined #openstack-tc20:38
openstackgerritMerged openstack/governance master: Update policy goal for watcher  https://review.openstack.org/52729920:38
*** lukebrowning has quit IRC20:41
*** kumarmn has quit IRC20:41
*** kumarmn has joined #openstack-tc20:41
openstackgerritMerged openstack/governance master: Add monasca-tempest-plugin to monasca project  https://review.openstack.org/52684620:45
openstackgerritMerged openstack/governance master: Mark the completion of Tempest Plugin Split goal for Freezer Team  https://review.openstack.org/52706120:54
openstackgerritMerged openstack/governance master: Add trove-tempest-plugin under trove project  https://review.openstack.org/52711920:54
openstackgerritMerged openstack/governance master: Add vitrage-tempest-plugin to vitrage project  https://review.openstack.org/52683820:54
openstackgerritMerged openstack/governance master: Update list of Neutron governed projects  https://review.openstack.org/52725520:54
openstackgerritMerged openstack/governance master: Retire puppet-apps_site  https://review.openstack.org/52694720:54
openstackgerritMerged openstack/governance master: Mark Cinder policy in code as done  https://review.openstack.org/52399820:54
openstackgerritMerged openstack/governance master: Add ec2api-tempest-plugin to ec2-api project  https://review.openstack.org/52684220:54
*** lukebrowning has joined #openstack-tc20:54
openstackgerritMerged openstack/governance master: Add telemetry-tempest-plugin to telemetry project  https://review.openstack.org/52686220:55
openstackgerritMerged openstack/governance master: Shift tripleo-ci from infra to tripleo  https://review.openstack.org/52671520:57
*** lukebrowning has quit IRC20:59
*** lukebrowning has joined #openstack-tc21:01
*** lukebrowning has quit IRC21:05
*** lukebrowning has joined #openstack-tc21:12
*** lukebrowning has quit IRC21:17
*** lukebrowning has joined #openstack-tc21:18
*** lukebrowning has quit IRC21:22
*** lukebrowning has joined #openstack-tc21:24
*** lukebrowning has quit IRC21:29
*** lukebrowning has joined #openstack-tc21:30
*** lukebrowning has quit IRC21:35
*** lukebrowning has joined #openstack-tc21:37
*** lukebrowning has quit IRC21:41
*** lukebrowning has joined #openstack-tc21:43
*** lukebrowning has quit IRC21:48
*** lukebrowning has joined #openstack-tc21:49
*** lukebrowning has quit IRC21:54
*** lukebrowning has joined #openstack-tc21:56
*** diablo_rojo_ has quit IRC21:59
*** lukebrowning has quit IRC22:01
*** lukebrowning has joined #openstack-tc22:02
*** kumarmn has quit IRC22:04
*** kumarmn has joined #openstack-tc22:05
*** lukebrowning has quit IRC22:07
*** kumarmn has quit IRC22:14
*** diablo_rojo has joined #openstack-tc22:14
*** kumarmn has joined #openstack-tc22:15
*** lukebrowning has joined #openstack-tc22:35
*** lukebrowning has quit IRC22:40
*** marst has quit IRC22:41
*** lukebrowning has joined #openstack-tc22:42
*** lukebrowning has quit IRC22:47
*** lukebrowning has joined #openstack-tc22:48
*** lukebrowning has quit IRC22:53
*** lukebrowning has joined #openstack-tc22:54
*** lukebrowning has quit IRC22:59
*** lukebrowning has joined #openstack-tc23:00
*** lukebrowning has quit IRC23:05
*** lukebrowning has joined #openstack-tc23:14
*** lukebrowning has quit IRC23:19
*** lukebrowning has joined #openstack-tc23:20
*** kumarmn has quit IRC23:25
*** lukebrowning has quit IRC23:25
*** kumarmn has joined #openstack-tc23:26
*** lukebrowning has joined #openstack-tc23:26
*** kumarmn has quit IRC23:30
*** kumarmn has joined #openstack-tc23:31
*** lukebrowning has quit IRC23:31
*** lukebrowning has joined #openstack-tc23:33
*** lukebrowning has quit IRC23:38
*** lukebrowning has joined #openstack-tc23:39
*** lukebrowning has quit IRC23:44
*** lukebrowning has joined #openstack-tc23:45
*** kumarmn has quit IRC23:48
*** lukebrowning has quit IRC23:50
*** lukebrowning has joined #openstack-tc23:56

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!