Thursday, 2018-02-08

*** kumarmn has joined #openstack-tc00:01
*** kumarmn has quit IRC00:05
*** mriedem has joined #openstack-tc00:10
*** diablo_rojo has quit IRC01:08
*** diablo_rojo has joined #openstack-tc01:09
smcginnisAnother post of possible interest to this group:
*** kumarmn has joined #openstack-tc01:30
*** liujiong has joined #openstack-tc01:39
*** kumarmn has quit IRC01:49
*** liujiong has quit IRC02:04
*** liujiong has joined #openstack-tc02:05
*** kumarmn has joined #openstack-tc02:12
*** kumarmn has quit IRC02:16
*** kumarmn has joined #openstack-tc02:32
*** kumarmn has quit IRC02:36
*** mriedem has quit IRC03:16
*** ykarel has joined #openstack-tc03:57
*** kumarmn has joined #openstack-tc04:04
*** kumarmn has quit IRC04:58
*** kumarmn has joined #openstack-tc04:58
*** kumarmn has quit IRC05:02
*** rosmaita has quit IRC05:52
*** coolsvap has joined #openstack-tc07:00
*** dtantsur|afk is now known as dtantsur08:09
*** mnaser has quit IRC08:17
*** kmalloc has quit IRC08:17
*** mnaser has joined #openstack-tc08:17
*** jbryce has quit IRC08:17
*** kmalloc has joined #openstack-tc08:18
*** eumel8 has joined #openstack-tc08:25
*** jpich has joined #openstack-tc08:54
*** liujiong has quit IRC09:18
ttxwow re: yaml2ical09:23
*** kumarmn has joined #openstack-tc09:59
*** jbryce has joined #openstack-tc10:00
*** kumarmn has quit IRC10:03
*** dtantsur is now known as dtantsur|bbl11:06
*** cdent has joined #openstack-tc11:10
cdentsmcginnis: yes, we have a spare room. The application process is complex but bribes are accepted.11:19
smcginnisI would love to live by the water. We have a lot of lakes here, but nothing as beautiful as that.11:20
smcginniscdent: I knew you were ill, but didn't realize it was that bad. Glad you're feeling better and getting out.11:21
cdentI'm still not 100%, which is really annoying, but at least capable of a half mile walk now.11:22
smcginnisWow. :/11:23
cdentI'm really good at being ill. :(11:23
smcginnisI guess we all need to excel at something.11:24
cdenti like squirrels11:25
*** ykarel_ has joined #openstack-tc12:32
*** ykarel has quit IRC12:34
*** ykarel__ has joined #openstack-tc12:36
*** ykarel_ has quit IRC12:39
*** liujiong has joined #openstack-tc12:39
*** ykarel__ is now known as ykarel12:44
*** liujiong has quit IRC12:45
*** coolsvap has quit IRC12:58
*** rosmaita has joined #openstack-tc13:17
*** coolsvap has joined #openstack-tc13:18
*** mriedem has joined #openstack-tc13:54
*** dtantsur|bbl is now known as dtantsur13:59
*** kumarmn has joined #openstack-tc14:06
*** ykarel_ has joined #openstack-tc14:11
*** ykarel has quit IRC14:11
fungisome of the recommendations in that article are very github-specific, but overall i feel like we do basically the same things when retiring projects in our community14:15
*** dtantsur is now known as dtantsur|brb14:55
persiaI found a lot of the recommendations specific to projects that are primarily controlled by a single entity: while there are some lessons we can learn, our project start criteria do a lot to reduce the load.14:56
*** ykarel_ is now known as ykarel14:58
fungivery true14:59
ttxtc-members: hi!15:00
fungitc-members: office hour-ish?15:00
cdentoh hi15:00
smcginnisYep, about that time.15:00
ttxLooking at the Rocky goals set, sounds like the mox one is being resisted a bit15:00
ttxWhat would be the plan B ?15:01
fungiyeah a rocky road for mox15:01
smcginnisThat was bad. :)15:01
smcginnisAnd by bad, I mean great.15:01
ttxI'd say mordred's pagination or masayuki's cold-upgrade15:01
smcginnisCold upgrade seemed to have some operator interest.15:02
smcginnisIt's at least something that more directly shows an end user benefit for the goal.15:02
fungii still wonder whether a tag and a goal are opposing ideas15:02
smcginnisThough I think reducing technical debt does result in end user benefit in the long run, it's a harder sell.15:02
ttxI wonder if substituting cold-upgrade for mox would not trigger more resistance15:02
fungior one is a path to the other15:02
ttxAlso hits the same teams15:02
ttxlike nova has nothing to do for both cold-upgrade and hot-debug15:03
dhellmannthe debug option toggle is already an operator feature; do we not want to include any technical debt goals this time?15:03
fungibut seems like a cold-upgrade goal, once complete, removes the point of having a cold-upgrade tag15:03
ttxwhile I suspect newer projects have both to cover15:03
smcginnisI have a feeling for some, the upgrade goal would end up being an "oh, we already do that but just don't have the tag"/15:03
ttxdhellmann: yes, that's why mox has my preference15:04
ttxgood mix of ops-facing and tech-debt reduction15:04
smcginnisIt was an interesting point brought up in there that carrying sqlalchemy-migrate is maybe a bigger thing than carrying mox3.15:04
dhellmannI'm ok with us moving from mox3 to that other thing fungi (I think) found15:04
smcginnisBut I have a feeling that would be a _much_ bigger lift.15:04
dhellmannsmcginnis : the difference there is that we're not asking the oslo team to keep managing sqlalchemy-migrate15:05
ttxObjections are mostly around (1) nova not completing the goal and therefore everyone else's effort to have limited impact, and (2) questioning how costly it actually is to maintain mox forever15:05
smcginnisdhellmann: A good distinction.15:05
dhellmannthe oslo team will be discussing plans for mox3 at the ptg. I intend to at least encourage them to take if off of their officially managed list of repos. The team is having trouble keeping up as it is.15:05
dhellmannmanaging it was supposed to be temporary anyway15:06
ttxdhellmann: so shall we punt on mox goal, given we need to explore solutions ?15:06
fungidhellmann: pymox (which was also the original name for mox at google if memory serves)15:06
johnthetubaguyso the change might/could be nova takes the pain of maintaining mox3 while that is the cheapest thing for them to do?15:06
smcginnisI think the other benefit is consistency with getting everyone to mock. It may not be a big deal maintaining mox3, but there's a different learning curve and awareness needed moving between projects, or even within projects, that use mox.15:06
dhellmannttx: that's fine with me. I just don't want people to be surprised if it support is officially dropped.15:06
johnthetubaguysmcginnis: at this point most new tests are mock AFAIK, this is a bulk move of old crud, so the gain isn't huge on that front15:07
ttxtc-members: which set do you prefer at this point ? (mox+debug) or (mox+upgrade) ?15:07
persiaMoving the mox3 repo to be a nova-team repo if everyone else moves seems a sensible solution.15:08
fungiwell, nova's already in the position that they have a mix of mox and mock testing, so it's not like they're disincentivized to ever complete thee mock migration even in absence of a community goal15:08
dhellmannttx: I prefer the upgrade goal, although I thought we dropped that one so my current vote does not reflect that.15:08
pabelangerI voted for +debug myself15:09
smcginnisttx: My vote is still mox+debug. But did you mean debug+upgrade for that second option?15:09
johnthetubaguyI like the debug thing, with my operator had that is crazy useful15:09
pabelangerjohnthetubaguy: +115:09
fungii like the debug config goal better than the cold upgrade one. i feel like the latter is well-intentioned but more of a guideline or base expectation we already have for all services regardless of the goal15:09
ttxerrr debug+upgrade yes15:09
ttxso (mox+debug) or (debug+upgrade)15:10
johnthetubaguyah, right, so then I lean mox+debug15:10
fungii'm in favor of the mox goal if it gives options... e.g.: move to mock or pymox or take on mox3 maintenance if you're the last team standing15:10
johnthetubaguymostly for similar reasons to fungi, its not that upgrade isn't important15:11
pabelangermox+debug, ++15:11
johnthetubaguyfungi: good point15:11
cmurphythe current goals are working well because we have one that is medium-effort with concensus that it is very important and one that is very low effort, so with mox being high effort and low concensus on importance i think it's not a good goal any more15:11
smcginnisfungi: So some disclaimer in the goal stating if it is not deemed possible for the project, that they at least switch to something other than our mox3?15:11
ttxI think the relevant objection to mox is that it's not fully qualified yet. We don't know what we'll be asking. Migrating to pymox or converting to mock15:11
fungii'm less in favor of the mox goal if we go into it knowing that at least some (specific) teams won't get there in a cycle15:11
smcginnisHave all projects completed the py3 goal yet?15:12
fungismcginnis: yeah, the goal sounds like it should be allowing the oslo team to stop maintainin mox315:12
ttxor is the goal "just stop using mox3/mox"15:12
smcginnisttx: That is my desired outcome.15:12
dhellmannfungi : well, the oslo team doesn't actually need anyone's permission to do that :-)15:12
johnthetubaguycmurphy: hmm, interesting... that is a very good point15:12
smcginnisBut being pragmatic, I could accept stop using mox3 as a fallback.15:12
fungidhellmann: fair. allowing them to do it in good conscience? ;)15:13
* dhellmann has a clear conscience15:13
ttxsmcginnis: so should we include the "pymox migration" as an option in the goal text ?15:13
johnthetubaguysmcginnis: how about: all new tests in mock, stop using mox315:13
dhellmannttx: I'm not sure migrating to pymox is enough work to be worth a "goal"15:13
fungii doubt pymox would be much of a migration (but haven't tried it). probably just switching some imports and reqs15:13
smcginnisttx: I think that would be OK as a fallback.15:14
dhellmannif it's not just a drop-in replacement (maybe with import updates) then maybe it is15:14
smcginnisjohnthetubaguy: I think our policy is already no new tests using mox, so not sure if that would be the best phrasing for the goal.15:14
johnthetubaguydhellmann: seems the import is the same...
fungiyeah, switching to pymox is certainly not goal-worthy on its own, just an alternative/fallback option for teams with too many mox-based tests to rewrite them in a cycle15:14
johnthetubaguysmcginnis: agreed, more a clarification15:14
smcginnisjohnthetubaguy: ++15:15
ttxfungi: should we mention that on the goal spec?15:15
ttxI'd really like us to be able to approve the goals this week or early next15:15
fungittx: providing fallback options in the goal would make it more palatable, i think, if the idea is that we're going into it knowing some teams think it's too aggressive for one cycle15:16
ttxThey both have majority vote so I could technically approve them now15:16
johnthetubaguyso just a move to pymox goal?15:16
ttxjohnthetubaguy: no... just say that if you don't manage to migrate them all, switch to pymox for the rest15:16
johnthetubaguyhmm, OK.15:16
fungijohnthetubaguy: switching whatever jobs you can't rewrite in rocky to use pymox instead15:16
cdentIt seems to me, as frustrating as this is to me personally because I'd like to think JFDI, if a goal requires this much discussion to work out the details for this many days, it's full of holes and needs to be flushed.15:17
cdentA _real_ goal is one where there is clear agreement on meaning. Otherwise it is not a goal at all.15:17
dhellmanncdent : I don't understand. Are you saying that goals must come in fully formed and obvious in order to be considered?15:17
dhellmannpart of the process is to have these discussions15:17
cdentdhellmann: no, not at all15:17
ttxcdent: a lot of the discussion is linked to the difficulty for us to pick a set of reviews, using Gerrit as a tool15:17
cdentbut we are weeks into it now15:17
fungii think the real contention here is that we've pushed back on other goals in the past when we knew they weren't able to be finished in a cycle. we either said come back when there's more progress already or split the goal into smaller steps15:18
cdentI completely agree that the discussion is critical15:18
dhellmannand as frustrated as *I* am with the "it's too much work and we don't care" response, that's part of the feedback we need to consider15:18
ttxGerrit is great for binary decisions15:18
dhellmannhow much time have we *actually* spent on it over those weeks, though?15:18
ttxnot so much in picking an ideal set15:18
mugsiecorrect me if this is wrong - but all of the objection to mox is from Nova, right?15:18
ttxAlso some of the discussion is testament that we have a great set of other proposals... not a judgment on the value of one specific one15:19
mugsiewe have said before that if one project wasn't going to do it, it wasn't a big deal15:19
fungimugsie: not all, there was at least one other team15:19
cdentmugsie: it seems that way yes, and that's a big source of the frustration15:19
ttxmugsie: yes, and some others objecting that a goal that nova can't fill should not be a goal15:19
ttx(which I don't really agree with)15:20
mugsieOK - but we covered this when we started the goals process15:20
dhellmannno, we can't let the entire community be bound by what the nova team is willing to do15:20
dhellmannor *any* one team15:20
cdentttx I think the objection was more philosophical than that. A thought experiment to point out nova's awkward position in our reality15:20
smcginnisI think a goal is still worthy, even if we know it will be difficult to impossible for a small subset of the community to complete.15:21
mugsiedhellmann: ++15:21
pabelangersmcginnis: ++15:21
smcginnisIt's at least some weight to get everyone moving in that direction.15:21
ttxSo.. any objection to moving on and approving the mox+debug set ? Or would you prefer to add a bit of precision to the mox one before approving it15:21
ttxTrying to see how to move forward here15:21
smcginnisI can add a caveat in there that pymox is a fallback plan.15:21
mugsieyeah - it makes sense - for some teams it is low hanging fruit and it reduces load on some horizontal teams15:22
ttxwe have 8 votes on each15:22
dhellmannare there constraints on that as a fallback? or do we just expect everyone to switch to pymox and call it done?15:22
smcginnisAnd only if absolutely no way to get the work done, with the expectation that the work will eventually happen.15:22
smcginnisdhellmann: Maybe a grading on goal completion?15:22
ttxdhellmann: only if you can't fix them all because there are too many of them (like nova)15:22
smcginnis90% got an A for moving off completely, nova gets a D+ for effort?15:22
johnthetubaguyso I think we should just do mox, its not like Nova hasn't been trying for a while:
smcginnisjohnthetubaguy: Right, good point. There's already effort.15:23
cdentI would prefer to not include the pymox fallback in the mox goal.15:23
smcginnisIf this drives more attention to nova unit test reviews and contributions, I think that's a win.15:23
ttxcdent: and approve it as-is ? Works for me15:23
* persia wonders if highlighting production installs of OpenStack software that don't include any Nova installation would help future discussions (although producing those as news from regular outlets might take a few months)15:23
dhellmannsmcginnis : part of the idea with the goal process was to set up easy completion criteria. I'm not sure how I feel about grades.15:23
cdentttx: yeah, and if a group can't or won't do it, that's just the way it goes15:24
ttxpymox is arguably just a workarounf to oslo's potential maint drop15:24
fungiyeah, i guess the question is if we do specify easier fallbacks, will all teams just do that because it's the path of least resistance? i hope not, but maybe that's a good reason not to specify particular fallbacks in the goal text after all15:24
ttxa bit orthogonal to using a single framework for tests, for sure15:24
smcginnisOK, does seem "safer" to not give an easy button in the goal.15:24
ttxAlright we have a plan15:24
ttxI'll drop "majority reached" notes on those reviews and say they are about to be approved15:25
fungihowever, for teams who _are_ unable to drop mox3 by the end of the cycle, it would still be nice to circle back around and make that happen through more expedient means15:25
ttxwe'll see if the sky falls15:25
fungiwe don't need to say it in the goal though i agree15:25
smcginnisfungi: ++15:25
smcginnisfungi: We can do that as an effort on our own outside the goal tracking.15:25
ttxOK, other topic is the PTG schedule, now set in stone at
fungiright. seems like it would be trivial by comparison15:26
ttxsmcginnis: I did add a "goal helproom" for those wanting ot make quick progress on that15:26
ttxThe PTG sold out yesterday, but we are looking at creative ways to add more tickets15:27
fungii have a lot of empathy on the mox->mock front, after having tried and failed to rewrite bindep's tests (i'm still a little fuzzy on mocking in tests)15:27
* EmilienM catching up15:27
ttxEmilienM: hola!15:27
ttxcmurphy: I see you -1ed the mox goal ?15:28
ttxjust as i thought we got consensus :)15:29
cmurphyttx: yes, but you still have majority i think15:29
ttxyes yes15:29
ttxbut that's a pretty weak one now15:29
cmurphyi think if our job is to represent the community and the community is speaking up and saying "no" to this then we should respect that15:29
ttxwell, "the community" might be a bit of an overstatement15:30
ttxSome people disagree, yes15:30
smcginnisI think part of our job is deciding what is best for OpenStack, regardless if it's like by all of the community.15:30
dhellmannconsensus != 100% agreement15:30
persiaIn general, political deliberative bodies (such as the TC) do well if each member represents some aspect of the community, rather than all representing everyone.  Dissent is important (if well understood).15:31
fungia minority of our community objected, and a minority of the tc have left negative rollcall votes. seems fine to me procedurally (it's not a veto, after all)15:31
EmilienMso far i'm the only member who voted for the cold-upgrade goal :)15:31
smcginnisYes, I do think cmurphy is raising very good points, so please don't take my own disagreement as dismissing those concerns.15:31
cmurphyfungi: that sounds fine to me15:32
ttxEmilienM: I'm having a hard time voting on individual proposals, I only consider sets15:32
EmilienMI haven't voted on the mox one but I wouldn't veto. mox is also a good goal imho15:32
*** ykarel is now known as ykarel|away15:32
ttxAnother PTG-related item: post-lunch stuff. Please vote/comment on
ttxWe already selected two -- an infra talk (probably Tuesday) and a "welcome" talk (Monday)15:34
cdentthis fits in here somewhere:
*** dtantsur|brb is now known as dtantsur15:34
ttxWho is interested in sharing the stage for the state of the union part of the "welcome" talk ? (spoiler: requires some work next week to prepare outline/slides)15:34
pabelangerwhat would that look like? Any notes that exist now?15:36
ttxpabelanger: notes @
smcginnisttx: I have a problem volunteering for things, but if you need a copresenter and no one else want to, I can definitely help out there.15:37
ttxIn particular would be great to have someone cover the "Looking forward to Rocky " part15:37
ttx    Bridging from Sydney Forum15:38
ttx    Rocky goals15:38
ttx    Other hard things we need to work on this cycle as a community15:38
*** coolsvap has quit IRC15:38
pabelangerYah, same. I can help volunteer if needed15:38
ttxI'm happy giving SoTU part since I have some data already15:38
* cdent is not volunteering.15:39
cdentjust being at the PTG is enough work :)15:39
ttxcdent is smart15:39
smcginniscdent: Smart man.15:39
ttxEmilienM: so what would you say should be the next step in goal selection ? Just mention on the weekly report tomorrow that mox+debug is still on track to be selected, has majority now and will be approved by Tuesday15:40
*** hongbin has joined #openstack-tc15:41
ttxor do you not feel comfortable with that choice and would rather have us pursue a different set ?15:41
ttxsince you coordinated the whole goal search I'd rather follow your lead there15:41
EmilienMmox+debug is good I think we should move forward15:41
ttxShould I just approve it tomorrow ? Or say I'll approve it on Tuesday ?15:42
ttx(we don't really have a house rule for such set approvals)15:43
EmilienMttx: Tuesday is fine15:43
cmurphyI wanted to ask about the powerstackers project application if there is time15:43
ttxyes please15:43
cmurphywith the qinling application it seemed like we really challenged them on "why do you want to be openstack" and "how are you furthering the openstack mission"15:44
cmurphyi don't see that happening with powerstackers so far15:44
cmurphyare they getting a pass because one of the projects was already official?15:44
ttxI see this one as more of a "this is a team that already exists, just wasn't registered properly"15:45
*** ykarel|away has quit IRC15:45
dhellmannmy questions on the qinling application were for the TC, more than the qinling team15:45
dhellmannI wanted to explore what criteria we're using to accept new teams and new projects in light of the foundation strategic area changes15:46
ttxI guess the only question that the PowerStackers application could rise is the old one around driver teams15:46
ttxLike, is the PowerStackers team really a level playing field15:46
dhellmannpowerstackers is more obviously an extension/integration with existing services so I didn't feel the need to raise those questions15:46
dhellmannis it less or more so than the winstackers?15:47
ttxsince arguably IBM people have access to information/hardware that others don't15:47
cmurphythat was my next question15:47
cmurphyseems sort of single-vendor driven15:47
ttxBut with the HyperV precedent (WinStackers) it's a hard line to trace15:47
dhellmannthe question isn't really how many companies contribute, but how many entities benefit from the results15:47
dhellmannat least for me, that's the question15:48
cmurphydhellmann: yes that's sort of what i meant i think15:48
dhellmanncdent : how do things stand with neutron and the driver team issue?15:48
ttxdhellmann: For me the question is whether we provide a level playing field. Like another company trying to participate, do they have the same status/chances as IBM15:48
dhellmannttx: yes, good point15:48
cdentdhellmann: it's been on my to do list for a while to check with miguel on that but I've flaked because of the usual excuses15:48
dhellmanncdent : ok. maybe the 3 of us can chat in dublin?15:49
ttxThe ONLY thing that being under OpenStack governance should give you is this independence from any specific org15:49
cdentlast we talked, though, he felt that things were moving forward in a positive direction and that third party CI was an important factor15:49
cdentdhellmann: that's a good idea15:49
dhellmannI'm fine with setting some objective criteria, I just want them written down so folks can move ahead with implementation if they want to.15:49
dhellmannin the case of powerstackers, do we think they are refusing contributions from non-IBM entities?15:50
ttxhmm... is PowerVM open source ?15:50
persiaIt was not as of March 2017: I haven't asked since15:51
ttxIf not, access to source code (and ability to modify it) definitely puts /some/ contributors at an unfair advantage over others15:51
dhellmannnetworking-powervm is clearly mostly IBM, but I see commits from NEC and VMware in there, too15:51
dhellmannthough, not many, it's not very active15:51
dhellmannif it comes down to diversity, it's 50% a single person :-)15:52
ttxBasically I'm not sure what being an official OpenStack project gives them.15:52
persiaThat would probably be one of the more important questions to ask :)15:52
ttxI guess I should register those questions... or are you going to cmurphy?15:53
dhellmannnova-powervm is also small
smcginniscdent, dhellmann: Last I talked to him, I got the impression the team policy had officially changed that they would allow third party drivers again, but were just waiting on a third party to propose one.15:53
dhellmannwhat do we gain by telling them no?15:53
ttxdhellmann: we do not dilute what makes an OpeNStack team ?15:53
dhellmannsmcginnis : maybe we just need to make sure the cisco folks know about that now15:53
ttxas in: a fair ground for open collaboration ?15:53
cdentanother way to look at the powervm situation is that members of that team are currently some of the leading contributors to nova-at-large15:53
persiadhellmann: I think the point is not to say "no", but by appreciating why they want "yes", it helps frame the sorts of services they expect (which informs how to oversee their governance).15:53
dhellmannttx: do we think they aren't going to be fair? or that there just isn't a lot of interest in contributing?15:54
smcginnisdhellmann: I was copied on an email to Cisco, IIRC, that offered it as an option to them.15:54
cdentyah, cisco is aware15:54
dhellmanncdent : yeah, I sort of saw this as a reorganization of some existing bits along the lines of what the winstackers team did15:54
dhellmannsmcginnis , cdent : ok, good, thanks15:54
ttxdhellmann: If some subgroup of contributors have access to relevant information that others can't access, it's pretty clearly a tilted playfield15:55
dhellmanndo they?15:55
ttxI guess the question is on "relevant information"15:55
cdentttx that's going to be true for any specialist drive across the board: hyperv, powervm, vmware, most of neutron, lots of cinder15:55
ttxI'd say that PowerVM drivers development benefit from unfettered access to PowerVM proprietary code15:56
ttxcdent: yes. But usually theuy don't make their own team15:56
ttxso the team remains a level playing field15:56
dhellmanndo the winstacker folks benefit from similar access to windows or hyperv code?15:56
ttxLike on Cinder it's overall a level playing field15:56
fungiyou could similarly argue that contributors from intel have inside information about processor features15:56
dhellmannare we saying we don't want them as a team any more?15:56
smcginnisI see them as a specialist subteam.15:57
ttxdhellmann: they got a free pass because they are actually not Microsoft15:57
smcginnisThere are users that fit that niche, and I see value in having a team that focuses on the overall solution space.15:57
ttxso they actually don't have access to that... in theory15:57
smcginnisSame as Winstackers.15:57
ttxbut yeah, it's hard to reject PowerStackers when we accepted WinStackers15:57
dhellmannttx: I'm not sure I'm comfortable with that distinction if we're going to reject this team15:58
ttxdhellmann: me neither tbh15:58
ttxI think the question of how they will ensure the team is a level playing field stays relevant though15:58
ttxI'll ask it on the review15:58
dhellmannif we have a software architecture that requires 3 separate libraries to handle the integration with external systems in 3 of our components, and some of the teams aren't going to host those things as "drivers" then for us to create a "level playing field" across the whole community I think we need to be prepared to have teams like this.15:59
ttxalso the whole "it's ok to develop drivers as part of a larger team, but not ok as a separate team" is a bit weak15:59
cmurphyi'm not against this team btw i was mostly wondering if i was missing context on formation of teams around drivers, sounds like i was a bit15:59
dhellmannand I'm not happy about that, because I would prefer to have those integration things inside their parent components in some way16:00
ttxdhellmann: yeah, we are back at the bottom of the drivers-team discussion16:00
cdentthat's a very lowercase woot16:00
ttxHow do we uphold our ideals of open collaboration and embrace driver devs16:00
ttxwith the various shades of grey solutions16:01
mugsieI thought nova explicitly said not to have external hypervisor drivers? or was it just that interface was unstable, and make break at any time?16:01
ttxyeah, woot16:01
cdentthose driver devs doing their dev out in the open is better than the alternative16:01
dhellmannttx: if they're doing their work in the open on our platform, how much more can we ask?16:01
fungithis does remind me of the stage of the driver teams discussion where i speculated what would happen if a vendor-specific deliverable wanted to move from a larger team to a new team of their own, and how we reconcile it being okay as part of another team but not as its own team16:02
mugsiedhellmann: ++16:02
ttxfungi: yes that's what I meant with "it's ok to develop drivers as part of a larger team, but not ok as a separate team" being a bit weak16:02
dhellmannmugsie : I think they've said their driver interface is not stable, but it's also not clear they have folks who want to review patches in the integration library16:02
ttxdhellmann: I guess we could approve those with a reminder that openstack teams are meant to be level playing fields, and then react if complaints are raised16:03
fungittx: yeah sorry, i'm still trying to catch up on the comments after revisiting the review16:03
ttxwhich is why I'm +2 on PowerStackers16:03
mugsieas long as I can get CI results without being employed by them ++16:03
ttx"assume good faith" kind of thing16:03
dhellmannttx: oh, yes, expect fire and brimstone from my side if any of these teams do show up as not collaborating -- I'll be the first to vote to drop them.16:03
cmurphyi don't expect this team not to play fair16:03
ttxbut we need to be clear about what being an openstack team means... while they are applying16:04
dhellmannright, I have no expectations of that either, cmurphy, which is why I voted yes16:04
ttxI'll comment something16:04
ttxyeah me neither, sounded more like a typo fix than a whole new thing16:04
dhellmannttx: that's fair. we should be doing that with all of our new teams.16:04
ttxGood question from mugsie though... does nova actually want nova-powervm to exist officially16:04
fungii'll need to read up more on powervm. i had assumed it was just hardware acceleration on powerpc platforms but apparently it's a lot more than that16:05
dhellmannttx: as a follow up, should any of our existing teams have veto power over new teams forming?16:05
cmurphydhellmann: though i think if i'm being honest with myself, my expectations are based on the fact that i already know some of the contributors, if this was a team of strangers i don't know what i'd expect16:05
ttxfungi: it's a bit of a house brand16:05
fungiso not the same as if we had a team form around, say, tools for integrating openstack on arm-based systems or whatever16:05
dhellmanncmurphy : it's good that you have that knowledge to bring to the discussion and I consider it fair to use it, or to ask questions if it was missing16:06
dhellmannwhen this came up before I remember us making a distinction about a 'driver' and an 'integration library' (or whatever we called it)16:07
dhellmannmy impression is that these things are more the latter16:07
fungithis discussion is helpful. i had been abstaining on that proposal while trying to gain a clearer picture of the technology involved16:08
mugsiedhellmann: re vetoing projects - 100% no. They could raise issues - but the decision should be from the TC based on all facts, not just that one team dislikes the proposal16:11
ttxOK commented16:12
ttxcmurphy: thanks for waking up that concern that was sleeping in me16:13
cmurphyno problem16:13
ttx(I somehow thought PowerVM was mostly open source)16:13
* cmurphy is a rabble rouser16:13
mtreinishttx: OpenPower != PowerVM16:14
mtreinishthe naming is confusing16:14
mtreinishespecially because the hardware is very similar between the 216:14
ttxyeah that's where they had me16:14
cdentcmurphy++ (rabble rousing)++16:15
*** masayukig has quit IRC16:29
*** masayukig has joined #openstack-tc16:30
*** thingee has joined #openstack-tc16:34
fungiconsider this rabble effectively roused16:35
*** ykarel|away has joined #openstack-tc16:40
*** eumel8 has quit IRC16:44
*** openstackgerrit has quit IRC16:48
*** hongbin has quit IRC16:48
*** hongbin has joined #openstack-tc16:50
*** ykarel|away has quit IRC16:51
*** jpich has quit IRC17:37
*** dtantsur is now known as dtantsur|afk17:58
cdentCan someone remind me where (if it exists) the etherpad for "Topics for the TC to talk about at the PTG" is?18:11
persiaNothing recorded at yet.  I don't see anything in a cursory look at the TC-related mail in my inbox.  I may have missed something.18:16
smcginnisI figured we would need to talk about goals and new projects yet, but maybe not.18:33
cdentI want to talk about matt's second paragraph in his comment on
smcginnisI just had a patch of mine downvoted the other day because the reviewer didn't like the name I used for one of the variables.18:45
smcginnisI'm still trying to decide if I care enough about the change, or if I just want to "drop it on the floor".18:45
cdentjroll I'm afrait that's not enough + you need a few more in order for me to hear you18:46
cdentnow I hear you18:47
jrollcdent: I believe we have a specific "how do we reduce the number of patch sets per change" on the ironic ptg agenda18:48
jrollwhich I think is the main question matt is asking there18:48
cdentcertainly an aspect thereof18:49
persiaI feel that number of gerrit changes per large concept change is different than number of concept changes landed in $time18:53
cdentI would guess that the topic is one we should revisit every time we are together, again and again. It's our core activity so we should be always working to make it better.18:54
dhellmanncdent : I'm not finding a bookmark for an etherpad like that. Maybe we don't have one?19:11
dhellmanncdent : how about
*** kong has quit IRC19:26
*** DuncanT has quit IRC19:26
*** kong has joined #openstack-tc19:27
cdentdhellmann: thanks!19:28
*** DuncanT has joined #openstack-tc19:30
cdentAre there fewer CFP submissions than desired? Seems like the social media press is pretty loud?19:32
*** lbragstad has joined #openstack-tc19:32
smcginnisOh how the turns have tabled.19:35
*** diablo_rojo has quit IRC19:37
fungiyeah, it depends on the culture of the review team to some extent19:48
fungilike in infra we have a bit of... i would almost call it public shaming that goes on when people get too picky and -1 a change over something trivial which doesn't ultimately impede the functionality of the code nor the ability to understand and maintain it over the long run19:49
fungii like to think of collaborative development a bit like a musical jam session19:50
smcginnisI like that.19:50
fungipeople have their own style, and they don't have to all become homogeneous clones to be able to create harmony19:51
fungiand if you have an accumulator in a loop in one function but do something similar with a list comprehension in another, who cares?19:51
fungican you read it and understand what it's doing? and does it do what needs to be done? then let's move on and spend time on more important work. we know there's plenty more where that came from19:52
*** ChanServ has quit IRC20:57
*** ChanServ has joined #openstack-tc21:30
*** sets mode: +o ChanServ21:30
*** diablo_rojo has joined #openstack-tc22:14
*** kumarmn has quit IRC22:16
cdentfungi: can you make your last statement fit on a t-shirt and print them up for ptg. "code review is: <what you said>"22:41
*** diablo_rojo has quit IRC22:51
jrollcode review is a words with colors jam session22:52
fungicollaborative scrabble23:00
*** kektrain has joined #openstack-tc23:08
*** kektrain has left #openstack-tc23:08
*** kektrain__ has joined #openstack-tc23:23
*** kektrain__ has left #openstack-tc23:23
*** cdent has quit IRC23:25
*** hongbin has quit IRC23:26
*** kumarmn has joined #openstack-tc23:32
*** kumarmn has quit IRC23:37

Generated by 2.15.3 by Marius Gedminas - find it at!