| *** kumarmn has joined #openstack-tc | 00:01 | |
| *** kumarmn has quit IRC | 00:05 | |
| *** mriedem has joined #openstack-tc | 00:10 | |
| *** diablo_rojo has quit IRC | 01:08 | |
| *** diablo_rojo has joined #openstack-tc | 01:09 | |
| smcginnis | Another post of possible interest to this group: http://todogroup.org/blog/shutting-down-an-open-source-project/ | 01:28 |
|---|---|---|
| *** kumarmn has joined #openstack-tc | 01:30 | |
| *** liujiong has joined #openstack-tc | 01:39 | |
| *** kumarmn has quit IRC | 01:49 | |
| *** liujiong has quit IRC | 02:04 | |
| *** liujiong has joined #openstack-tc | 02:05 | |
| *** kumarmn has joined #openstack-tc | 02:12 | |
| *** kumarmn has quit IRC | 02:16 | |
| *** kumarmn has joined #openstack-tc | 02:32 | |
| *** kumarmn has quit IRC | 02:36 | |
| *** mriedem has quit IRC | 03:16 | |
| *** ykarel has joined #openstack-tc | 03:57 | |
| *** kumarmn has joined #openstack-tc | 04:04 | |
| *** kumarmn has quit IRC | 04:58 | |
| *** kumarmn has joined #openstack-tc | 04:58 | |
| *** kumarmn has quit IRC | 05:02 | |
| *** rosmaita has quit IRC | 05:52 | |
| *** coolsvap has joined #openstack-tc | 07:00 | |
| *** dtantsur|afk is now known as dtantsur | 08:09 | |
| *** mnaser has quit IRC | 08:17 | |
| *** kmalloc has quit IRC | 08:17 | |
| *** mnaser has joined #openstack-tc | 08:17 | |
| *** jbryce has quit IRC | 08:17 | |
| *** kmalloc has joined #openstack-tc | 08:18 | |
| *** eumel8 has joined #openstack-tc | 08:25 | |
| *** jpich has joined #openstack-tc | 08:54 | |
| *** liujiong has quit IRC | 09:18 | |
| ttx | wow re: yaml2ical | 09:23 |
| *** kumarmn has joined #openstack-tc | 09:59 | |
| *** jbryce has joined #openstack-tc | 10:00 | |
| *** kumarmn has quit IRC | 10:03 | |
| *** dtantsur is now known as dtantsur|bbl | 11:06 | |
| *** cdent has joined #openstack-tc | 11:10 | |
| cdent | smcginnis: yes, we have a spare room. The application process is complex but bribes are accepted. | 11:19 |
| smcginnis | ;) | 11:19 |
| smcginnis | I would love to live by the water. We have a lot of lakes here, but nothing as beautiful as that. | 11:20 |
| smcginnis | cdent: I knew you were ill, but didn't realize it was that bad. Glad you're feeling better and getting out. | 11:21 |
| cdent | I'm still not 100%, which is really annoying, but at least capable of a half mile walk now. | 11:22 |
| smcginnis | Wow. :/ | 11:23 |
| cdent | I'm really good at being ill. :( | 11:23 |
| smcginnis | I guess we all need to excel at something. | 11:24 |
| cdent | i like squirrels | 11:25 |
| *** ykarel_ has joined #openstack-tc | 12:32 | |
| *** ykarel has quit IRC | 12:34 | |
| *** ykarel__ has joined #openstack-tc | 12:36 | |
| *** ykarel_ has quit IRC | 12:39 | |
| *** liujiong has joined #openstack-tc | 12:39 | |
| *** ykarel__ is now known as ykarel | 12:44 | |
| *** liujiong has quit IRC | 12:45 | |
| *** coolsvap has quit IRC | 12:58 | |
| *** rosmaita has joined #openstack-tc | 13:17 | |
| *** coolsvap has joined #openstack-tc | 13:18 | |
| *** mriedem has joined #openstack-tc | 13:54 | |
| *** dtantsur|bbl is now known as dtantsur | 13:59 | |
| *** kumarmn has joined #openstack-tc | 14:06 | |
| *** ykarel_ has joined #openstack-tc | 14:11 | |
| *** ykarel has quit IRC | 14:11 | |
| fungi | some 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 community | 14:15 |
| *** dtantsur is now known as dtantsur|brb | 14:55 | |
| persia | I 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 ykarel | 14:58 | |
| fungi | very true | 14:59 |
| ttx | tc-members: hi! | 15:00 |
| fungi | tc-members: office hour-ish? | 15:00 |
| cmurphy | hello | 15:00 |
| cdent | oh hi | 15:00 |
| smcginnis | Yep, about that time. | 15:00 |
| pabelanger | hello | 15:00 |
| ttx | Looking at the Rocky goals set, sounds like the mox one is being resisted a bit | 15:00 |
| ttx | What would be the plan B ? | 15:01 |
| fungi | yeah a rocky road for mox | 15:01 |
| smcginnis | That was bad. :) | 15:01 |
| smcginnis | And by bad, I mean great. | 15:01 |
| ttx | I'd say mordred's pagination or masayuki's cold-upgrade | 15:01 |
| smcginnis | Cold upgrade seemed to have some operator interest. | 15:02 |
| dhellmann | o/ | 15:02 |
| johnthetubaguy | o/ | 15:02 |
| smcginnis | It's at least something that more directly shows an end user benefit for the goal. | 15:02 |
| fungi | i still wonder whether a tag and a goal are opposing ideas | 15:02 |
| smcginnis | Though I think reducing technical debt does result in end user benefit in the long run, it's a harder sell. | 15:02 |
| ttx | I wonder if substituting cold-upgrade for mox would not trigger more resistance | 15:02 |
| fungi | or one is a path to the other | 15:02 |
| ttx | Also hits the same teams | 15:02 |
| ttx | like nova has nothing to do for both cold-upgrade and hot-debug | 15:03 |
| dhellmann | the debug option toggle is already an operator feature; do we not want to include any technical debt goals this time? | 15:03 |
| fungi | but seems like a cold-upgrade goal, once complete, removes the point of having a cold-upgrade tag | 15:03 |
| ttx | while I suspect newer projects have both to cover | 15:03 |
| smcginnis | I 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 |
| ttx | dhellmann: yes, that's why mox has my preference | 15:04 |
| ttx | good mix of ops-facing and tech-debt reduction | 15:04 |
| smcginnis | It was an interesting point brought up in there that carrying sqlalchemy-migrate is maybe a bigger thing than carrying mox3. | 15:04 |
| dhellmann | I'm ok with us moving from mox3 to that other thing fungi (I think) found | 15:04 |
| smcginnis | But I have a feeling that would be a _much_ bigger lift. | 15:04 |
| dhellmann | smcginnis : the difference there is that we're not asking the oslo team to keep managing sqlalchemy-migrate | 15:05 |
| ttx | Objections 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 forever | 15:05 |
| smcginnis | dhellmann: A good distinction. | 15:05 |
| dhellmann | the 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 |
| dhellmann | managing it was supposed to be temporary anyway | 15:06 |
| ttx | dhellmann: so shall we punt on mox goal, given we need to explore solutions ? | 15:06 |
| fungi | dhellmann: pymox (which was also the original name for mox at google if memory serves) | 15:06 |
| johnthetubaguy | so the change might/could be nova takes the pain of maintaining mox3 while that is the cheapest thing for them to do? | 15:06 |
| smcginnis | I 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 |
| dhellmann | ttx: that's fine with me. I just don't want people to be surprised if it support is officially dropped. | 15:06 |
| johnthetubaguy | smcginnis: 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 front | 15:07 |
| ttx | tc-members: which set do you prefer at this point ? (mox+debug) or (mox+upgrade) ? | 15:07 |
| persia | Moving the mox3 repo to be a nova-team repo if everyone else moves seems a sensible solution. | 15:08 |
| fungi | well, 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 goal | 15:08 |
| dhellmann | ttx: I prefer the upgrade goal, although I thought we dropped that one so my current vote does not reflect that. | 15:08 |
| pabelanger | I voted for +debug myself | 15:09 |
| smcginnis | ttx: My vote is still mox+debug. But did you mean debug+upgrade for that second option? | 15:09 |
| johnthetubaguy | I like the debug thing, with my operator had that is crazy useful | 15:09 |
| pabelanger | johnthetubaguy: +1 | 15:09 |
| johnthetubaguy | s/had/hat | 15:09 |
| fungi | i 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 goal | 15:09 |
| ttx | errr debug+upgrade yes | 15:09 |
| ttx | so (mox+debug) or (debug+upgrade) | 15:10 |
| johnthetubaguy | ah, right, so then I lean mox+debug | 15:10 |
| fungi | i'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 standing | 15:10 |
| johnthetubaguy | mostly for similar reasons to fungi, its not that upgrade isn't important | 15:11 |
| pabelanger | mox+debug, ++ | 15:11 |
| johnthetubaguy | fungi: good point | 15:11 |
| cmurphy | the 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 more | 15:11 |
| smcginnis | fungi: 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 |
| ttx | I 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 mock | 15:11 |
| fungi | i'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 cycle | 15:11 |
| smcginnis | Have all projects completed the py3 goal yet? | 15:12 |
| fungi | smcginnis: yeah, the goal sounds like it should be allowing the oslo team to stop maintainin mox3 | 15:12 |
| fungi | maintaining | 15:12 |
| ttx | or is the goal "just stop using mox3/mox" | 15:12 |
| smcginnis | ttx: That is my desired outcome. | 15:12 |
| dhellmann | fungi : well, the oslo team doesn't actually need anyone's permission to do that :-) | 15:12 |
| johnthetubaguy | cmurphy: hmm, interesting... that is a very good point | 15:12 |
| smcginnis | But being pragmatic, I could accept stop using mox3 as a fallback. | 15:12 |
| fungi | dhellmann: fair. allowing them to do it in good conscience? ;) | 15:13 |
| * dhellmann has a clear conscience | 15:13 | |
| ttx | smcginnis: so should we include the "pymox migration" as an option in the goal text ? | 15:13 |
| johnthetubaguy | smcginnis: how about: all new tests in mock, stop using mox3 | 15:13 |
| dhellmann | ttx: I'm not sure migrating to pymox is enough work to be worth a "goal" | 15:13 |
| fungi | i doubt pymox would be much of a migration (but haven't tried it). probably just switching some imports and reqs | 15:13 |
| smcginnis | ttx: I think that would be OK as a fallback. | 15:14 |
| dhellmann | if it's not just a drop-in replacement (maybe with import updates) then maybe it is | 15:14 |
| smcginnis | johnthetubaguy: 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 |
| johnthetubaguy | dhellmann: seems the import is the same... http://pymox.readthedocs.io/en/latest/ | 15:14 |
| fungi | yeah, 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 cycle | 15:14 |
| johnthetubaguy | smcginnis: agreed, more a clarification | 15:14 |
| smcginnis | johnthetubaguy: ++ | 15:15 |
| ttx | fungi: should we mention that on the goal spec? | 15:15 |
| ttx | I'd really like us to be able to approve the goals this week or early next | 15:15 |
| fungi | ttx: 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 cycle | 15:16 |
| ttx | They both have majority vote so I could technically approve them now | 15:16 |
| johnthetubaguy | so just a move to pymox goal? | 15:16 |
| ttx | johnthetubaguy: no... just say that if you don't manage to migrate them all, switch to pymox for the rest | 15:16 |
| johnthetubaguy | hmm, OK. | 15:16 |
| fungi | johnthetubaguy: switching whatever jobs you can't rewrite in rocky to use pymox instead | 15:16 |
| cdent | It 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 |
| cdent | A _real_ goal is one where there is clear agreement on meaning. Otherwise it is not a goal at all. | 15:17 |
| dhellmann | cdent : I don't understand. Are you saying that goals must come in fully formed and obvious in order to be considered? | 15:17 |
| dhellmann | part of the process is to have these discussions | 15:17 |
| cdent | dhellmann: no, not at all | 15:17 |
| ttx | cdent: a lot of the discussion is linked to the difficulty for us to pick a set of reviews, using Gerrit as a tool | 15:17 |
| cdent | but we are weeks into it now | 15:17 |
| fungi | i 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 steps | 15:18 |
| cdent | I completely agree that the discussion is critical | 15:18 |
| dhellmann | and 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 consider | 15:18 |
| ttx | Gerrit is great for binary decisions | 15:18 |
| dhellmann | how much time have we *actually* spent on it over those weeks, though? | 15:18 |
| ttx | not so much in picking an ideal set | 15:18 |
| mugsie | correct me if this is wrong - but all of the objection to mox is from Nova, right? | 15:18 |
| ttx | Also some of the discussion is testament that we have a great set of other proposals... not a judgment on the value of one specific one | 15:19 |
| mugsie | we have said before that if one project wasn't going to do it, it wasn't a big deal | 15:19 |
| fungi | mugsie: not all, there was at least one other team | 15:19 |
| cdent | mugsie: it seems that way yes, and that's a big source of the frustration | 15:19 |
| ttx | mugsie: yes, and some others objecting that a goal that nova can't fill should not be a goal | 15:19 |
| ttx | (which I don't really agree with) | 15:20 |
| mugsie | OK - but we covered this when we started the goals process | 15:20 |
| ttx | indeed | 15:20 |
| dhellmann | no, we can't let the entire community be bound by what the nova team is willing to do | 15:20 |
| dhellmann | or *any* one team | 15:20 |
| cdent | ttx I think the objection was more philosophical than that. A thought experiment to point out nova's awkward position in our reality | 15:20 |
| smcginnis | I 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 |
| mugsie | dhellmann: ++ | 15:21 |
| pabelanger | smcginnis: ++ | 15:21 |
| smcginnis | It's at least some weight to get everyone moving in that direction. | 15:21 |
| ttx | So.. 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 it | 15:21 |
| ttx | Trying to see how to move forward here | 15:21 |
| smcginnis | I can add a caveat in there that pymox is a fallback plan. | 15:21 |
| mugsie | yeah - it makes sense - for some teams it is low hanging fruit and it reduces load on some horizontal teams | 15:22 |
| ttx | we have 8 votes on each | 15:22 |
| dhellmann | are there constraints on that as a fallback? or do we just expect everyone to switch to pymox and call it done? | 15:22 |
| smcginnis | And only if absolutely no way to get the work done, with the expectation that the work will eventually happen. | 15:22 |
| smcginnis | dhellmann: Maybe a grading on goal completion? | 15:22 |
| ttx | dhellmann: only if you can't fix them all because there are too many of them (like nova) | 15:22 |
| smcginnis | 90% got an A for moving off completely, nova gets a D+ for effort? | 15:22 |
| johnthetubaguy | so I think we should just do mox, its not like Nova hasn't been trying for a while: https://blueprints.launchpad.net/nova/+spec/remove-mox | 15:23 |
| smcginnis | johnthetubaguy: Right, good point. There's already effort. | 15:23 |
| cdent | I would prefer to not include the pymox fallback in the mox goal. | 15:23 |
| smcginnis | If this drives more attention to nova unit test reviews and contributions, I think that's a win. | 15:23 |
| ttx | cdent: and approve it as-is ? Works for me | 15: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 | |
| dhellmann | smcginnis : 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 |
| cdent | ttx: yeah, and if a group can't or won't do it, that's just the way it goes | 15:24 |
| ttx | pymox is arguably just a workarounf to oslo's potential maint drop | 15:24 |
| fungi | yeah, 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 all | 15:24 |
| ttx | a bit orthogonal to using a single framework for tests, for sure | 15:24 |
| smcginnis | OK, does seem "safer" to not give an easy button in the goal. | 15:24 |
| cdent | smcginnis++ | 15:24 |
| pabelanger | ++ | 15:24 |
| johnthetubaguy | ++ | 15:24 |
| ttx | Alright we have a plan | 15:24 |
| ttx | I'll drop "majority reached" notes on those reviews and say they are about to be approved | 15:25 |
| fungi | however, 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 means | 15:25 |
| ttx | we'll see if the sky falls | 15:25 |
| fungi | we don't need to say it in the goal though i agree | 15:25 |
| smcginnis | fungi: ++ | 15:25 |
| johnthetubaguy | ++ | 15:25 |
| smcginnis | fungi: We can do that as an effort on our own outside the goal tracking. | 15:25 |
| ttx | OK, other topic is the PTG schedule, now set in stone at https://www.openstack.org/ptg#tab_schedule | 15:26 |
| fungi | right. seems like it would be trivial by comparison | 15:26 |
| ttx | smcginnis: I did add a "goal helproom" for those wanting ot make quick progress on that | 15:26 |
| ttx | The PTG sold out yesterday, but we are looking at creative ways to add more tickets | 15:27 |
| fungi | i 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 | hello | 15:27 |
| * EmilienM catching up | 15:27 | |
| ttx | EmilienM: hola! | 15:27 |
| ttx | cmurphy: I see you -1ed the mox goal ? | 15:28 |
| ttx | just as i thought we got consensus :) | 15:29 |
| cmurphy | ttx: yes, but you still have majority i think | 15:29 |
| ttx | yes yes | 15:29 |
| ttx | but that's a pretty weak one now | 15:29 |
| cmurphy | i think if our job is to represent the community and the community is speaking up and saying "no" to this then we should respect that | 15:29 |
| ttx | well, "the community" might be a bit of an overstatement | 15:30 |
| ttx | Some people disagree, yes | 15:30 |
| smcginnis | I think part of our job is deciding what is best for OpenStack, regardless if it's like by all of the community. | 15:30 |
| smcginnis | *liked | 15:30 |
| dhellmann | consensus != 100% agreement | 15:30 |
| persia | In 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 |
| fungi | a 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 |
| EmilienM | so far i'm the only member who voted for the cold-upgrade goal :) | 15:31 |
| smcginnis | Yes, I do think cmurphy is raising very good points, so please don't take my own disagreement as dismissing those concerns. | 15:31 |
| cmurphy | fungi: that sounds fine to me | 15:32 |
| ttx | EmilienM: I'm having a hard time voting on individual proposals, I only consider sets | 15:32 |
| EmilienM | I haven't voted on the mox one but I wouldn't veto. mox is also a good goal imho | 15:32 |
| *** ykarel is now known as ykarel|away | 15:32 | |
| ttx | Another PTG-related item: post-lunch stuff. Please vote/comment on https://etherpad.openstack.org/p/dublin-PTG-postlunch | 15:33 |
| ttx | We already selected two -- an infra talk (probably Tuesday) and a "welcome" talk (Monday) | 15:34 |
| cdent | this fits in here somewhere: http://sifter.org/~brandyn/Democracy.png | 15:34 |
| *** dtantsur|brb is now known as dtantsur | 15:34 | |
| ttx | Who 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 |
| pabelanger | what would that look like? Any notes that exist now? | 15:36 |
| ttx | pabelanger: notes @ https://etherpad.openstack.org/p/dublin-PTG-postlunch-monday | 15:36 |
| smcginnis | ttx: 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 |
| ttx | In particular would be great to have someone cover the "Looking forward to Rocky " part | 15:37 |
| ttx | Bridging from Sydney Forum | 15:38 |
| ttx | Rocky goals | 15:38 |
| ttx | Other hard things we need to work on this cycle as a community | 15:38 |
| *** coolsvap has quit IRC | 15:38 | |
| pabelanger | Yah, same. I can help volunteer if needed | 15:38 |
| ttx | I'm happy giving SoTU part since I have some data already | 15:38 |
| * cdent is not volunteering. | 15:39 | |
| cdent | just being at the PTG is enough work :) | 15:39 |
| ttx | cdent is smart | 15:39 |
| cmurphy | indeed | 15:39 |
| smcginnis | cdent: Smart man. | 15:39 |
| ttx | EmilienM: 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 Tuesday | 15:40 |
| ttx | ? | 15:40 |
| *** hongbin has joined #openstack-tc | 15:41 | |
| ttx | or do you not feel comfortable with that choice and would rather have us pursue a different set ? | 15:41 |
| ttx | since you coordinated the whole goal search I'd rather follow your lead there | 15:41 |
| EmilienM | mox+debug is good I think we should move forward | 15:41 |
| ttx | Should 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 |
| EmilienM | ttx: Tuesday is fine | 15:43 |
| ttx | ok | 15:43 |
| cmurphy | I wanted to ask about the powerstackers project application if there is time | 15:43 |
| ttx | yes please | 15:43 |
| cmurphy | with 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 |
| cmurphy | i don't see that happening with powerstackers so far | 15:44 |
| cmurphy | are they getting a pass because one of the projects was already official? | 15:44 |
| ttx | I 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 IRC | 15:45 | |
| dhellmann | my questions on the qinling application were for the TC, more than the qinling team | 15:45 |
| dhellmann | I wanted to explore what criteria we're using to accept new teams and new projects in light of the foundation strategic area changes | 15:46 |
| ttx | I guess the only question that the PowerStackers application could rise is the old one around driver teams | 15:46 |
| ttx | Like, is the PowerStackers team really a level playing field | 15:46 |
| dhellmann | powerstackers is more obviously an extension/integration with existing services so I didn't feel the need to raise those questions | 15:46 |
| dhellmann | is it less or more so than the winstackers? | 15:47 |
| ttx | since arguably IBM people have access to information/hardware that others don't | 15:47 |
| cmurphy | that was my next question | 15:47 |
| cmurphy | seems sort of single-vendor driven | 15:47 |
| ttx | But with the HyperV precedent (WinStackers) it's a hard line to trace | 15:47 |
| dhellmann | the question isn't really how many companies contribute, but how many entities benefit from the results | 15:47 |
| dhellmann | at least for me, that's the question | 15:48 |
| cmurphy | dhellmann: yes that's sort of what i meant i think | 15:48 |
| dhellmann | cdent : how do things stand with neutron and the driver team issue? | 15:48 |
| ttx | dhellmann: 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 IBM | 15:48 |
| dhellmann | ttx: yes, good point | 15:48 |
| cdent | dhellmann: 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 excuses | 15:48 |
| dhellmann | cdent : ok. maybe the 3 of us can chat in dublin? | 15:49 |
| ttx | The ONLY thing that being under OpenStack governance should give you is this independence from any specific org | 15:49 |
| cdent | last we talked, though, he felt that things were moving forward in a positive direction and that third party CI was an important factor | 15:49 |
| cdent | dhellmann: that's a good idea | 15:49 |
| dhellmann | I'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 |
| dhellmann | in the case of powerstackers, do we think they are refusing contributions from non-IBM entities? | 15:50 |
| cdent | ✔ | 15:50 |
| ttx | hmm... is PowerVM open source ? | 15:50 |
| persia | It was not as of March 2017: I haven't asked since | 15:51 |
| ttx | If not, access to source code (and ability to modify it) definitely puts /some/ contributors at an unfair advantage over others | 15:51 |
| dhellmann | networking-powervm is clearly mostly IBM, but I see commits from NEC and VMware in there, too | 15:51 |
| dhellmann | though, not many, it's not very active | 15:51 |
| dhellmann | http://stackalytics.com/?project_type=openstack-others&module=networking-powervm&metric=commits | 15:51 |
| dhellmann | if it comes down to diversity, it's 50% a single person :-) | 15:52 |
| ttx | Basically I'm not sure what being an official OpenStack project gives them. | 15:52 |
| persia | That would probably be one of the more important questions to ask :) | 15:52 |
| ttx | I guess I should register those questions... or are you going to cmurphy? | 15:53 |
| dhellmann | nova-powervm is also small http://stackalytics.com/?project_type=openstack-others&module=nova-powervm&metric=commits | 15:53 |
| smcginnis | cdent, 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 |
| dhellmann | what do we gain by telling them no? | 15:53 |
| ttx | dhellmann: we do not dilute what makes an OpeNStack team ? | 15:53 |
| dhellmann | smcginnis : maybe we just need to make sure the cisco folks know about that now | 15:53 |
| ttx | as in: a fair ground for open collaboration ? | 15:53 |
| cdent | another way to look at the powervm situation is that members of that team are currently some of the leading contributors to nova-at-large | 15:53 |
| persia | dhellmann: 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 |
| dhellmann | ttx: do we think they aren't going to be fair? or that there just isn't a lot of interest in contributing? | 15:54 |
| smcginnis | dhellmann: I was copied on an email to Cisco, IIRC, that offered it as an option to them. | 15:54 |
| cdent | yah, cisco is aware | 15:54 |
| dhellmann | cdent : yeah, I sort of saw this as a reorganization of some existing bits along the lines of what the winstackers team did | 15:54 |
| dhellmann | smcginnis , cdent : ok, good, thanks | 15:54 |
| ttx | dhellmann: If some subgroup of contributors have access to relevant information that others can't access, it's pretty clearly a tilted playfield | 15:55 |
| dhellmann | do they? | 15:55 |
| ttx | I guess the question is on "relevant information" | 15:55 |
| cdent | ttx that's going to be true for any specialist drive across the board: hyperv, powervm, vmware, most of neutron, lots of cinder | 15:55 |
| ttx | I'd say that PowerVM drivers development benefit from unfettered access to PowerVM proprietary code | 15:56 |
| ttx | cdent: yes. But usually theuy don't make their own team | 15:56 |
| ttx | so the team remains a level playing field | 15:56 |
| dhellmann | do the winstacker folks benefit from similar access to windows or hyperv code? | 15:56 |
| ttx | Like on Cinder it's overall a level playing field | 15:56 |
| fungi | you could similarly argue that contributors from intel have inside information about processor features | 15:56 |
| dhellmann | are we saying we don't want them as a team any more? | 15:56 |
| smcginnis | I see them as a specialist subteam. | 15:57 |
| ttx | dhellmann: they got a free pass because they are actually not Microsoft | 15:57 |
| smcginnis | There are users that fit that niche, and I see value in having a team that focuses on the overall solution space. | 15:57 |
| ttx | so they actually don't have access to that... in theory | 15:57 |
| smcginnis | Same as Winstackers. | 15:57 |
| ttx | but yeah, it's hard to reject PowerStackers when we accepted WinStackers | 15:57 |
| dhellmann | ttx: I'm not sure I'm comfortable with that distinction if we're going to reject this team | 15:58 |
| ttx | dhellmann: me neither tbh | 15:58 |
| ttx | I think the question of how they will ensure the team is a level playing field stays relevant though | 15:58 |
| ttx | I'll ask it on the review | 15:58 |
| dhellmann | if 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 |
| ttx | also the whole "it's ok to develop drivers as part of a larger team, but not ok as a separate team" is a bit weak | 15:59 |
| cmurphy | i'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 bit | 15:59 |
| dhellmann | and I'm not happy about that, because I would prefer to have those integration things inside their parent components in some way | 16:00 |
| ttx | dhellmann: yeah, we are back at the bottom of the drivers-team discussion | 16:00 |
| dhellmann | right | 16:00 |
| cdent | woot | 16:00 |
| cdent | that's a very lowercase woot | 16:00 |
| ttx | How do we uphold our ideals of open collaboration and embrace driver devs | 16:00 |
| ttx | with the various shades of grey solutions | 16:01 |
| mugsie | I 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 |
| ttx | yeah, woot | 16:01 |
| cdent | those driver devs doing their dev out in the open is better than the alternative | 16:01 |
| dhellmann | ttx: if they're doing their work in the open on our platform, how much more can we ask? | 16:01 |
| fungi | this 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 team | 16:02 |
| mugsie | dhellmann: ++ | 16:02 |
| ttx | fungi: 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 weak | 16:02 |
| dhellmann | mugsie : 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 library | 16:02 |
| ttx | dhellmann: 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 raised | 16:03 |
| fungi | ttx: yeah sorry, i'm still trying to catch up on the comments after revisiting the review | 16:03 |
| ttx | which is why I'm +2 on PowerStackers | 16:03 |
| mugsie | as long as I can get CI results without being employed by them ++ | 16:03 |
| ttx | "assume good faith" kind of thing | 16:03 |
| dhellmann | ttx: 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 |
| cmurphy | i don't expect this team not to play fair | 16:03 |
| ttx | but we need to be clear about what being an openstack team means... while they are applying | 16:04 |
| dhellmann | right, I have no expectations of that either, cmurphy, which is why I voted yes | 16:04 |
| ttx | I'll comment something | 16:04 |
| ttx | yeah me neither, sounded more like a typo fix than a whole new thing | 16:04 |
| dhellmann | ttx: that's fair. we should be doing that with all of our new teams. | 16:04 |
| ttx | Good question from mugsie though... does nova actually want nova-powervm to exist officially | 16:04 |
| fungi | i'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 that | 16:05 |
| dhellmann | ttx: as a follow up, should any of our existing teams have veto power over new teams forming? | 16:05 |
| cmurphy | dhellmann: 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 expect | 16:05 |
| ttx | fungi: it's a bit of a house brand | 16:05 |
| fungi | so not the same as if we had a team form around, say, tools for integrating openstack on arm-based systems or whatever | 16:05 |
| dhellmann | cmurphy : 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 missing | 16:06 |
| dhellmann | when this came up before I remember us making a distinction about a 'driver' and an 'integration library' (or whatever we called it) | 16:07 |
| dhellmann | my impression is that these things are more the latter | 16:07 |
| fungi | this discussion is helpful. i had been abstaining on that proposal while trying to gain a clearer picture of the technology involved | 16:08 |
| mugsie | dhellmann: 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 proposal | 16:11 |
| ttx | OK commented | 16:12 |
| ttx | cmurphy: thanks for waking up that concern that was sleeping in me | 16:13 |
| cmurphy | no problem | 16:13 |
| ttx | (I somehow thought PowerVM was mostly open source) | 16:13 |
| * cmurphy is a rabble rouser | 16:13 | |
| mtreinish | ttx: OpenPower != PowerVM | 16:14 |
| mtreinish | the naming is confusing | 16:14 |
| mtreinish | especially because the hardware is very similar between the 2 | 16:14 |
| ttx | yeah that's where they had me | 16:14 |
| cdent | cmurphy++ (rabble rousing)++ | 16:15 |
| *** masayukig has quit IRC | 16:29 | |
| *** masayukig has joined #openstack-tc | 16:30 | |
| *** thingee has joined #openstack-tc | 16:34 | |
| fungi | consider this rabble effectively roused | 16:35 |
| *** ykarel|away has joined #openstack-tc | 16:40 | |
| *** eumel8 has quit IRC | 16:44 | |
| *** openstackgerrit has quit IRC | 16:48 | |
| *** hongbin has quit IRC | 16:48 | |
| *** hongbin has joined #openstack-tc | 16:50 | |
| *** ykarel|away has quit IRC | 16:51 | |
| *** jpich has quit IRC | 17:37 | |
| *** dtantsur is now known as dtantsur|afk | 17:58 | |
| cdent | Can someone remind me where (if it exists) the etherpad for "Topics for the TC to talk about at the PTG" is? | 18:11 |
| persia | Nothing recorded at https://wiki.openstack.org/wiki/PTG/Rocky/Etherpads 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 |
| smcginnis | I figured we would need to talk about goals and new projects yet, but maybe not. | 18:33 |
| cdent | I want to talk about matt's second paragraph in his comment on https://anticdent.org/openstack-developer-satisfaction.html | 18:41 |
| jroll | ++++++++++++++++++++++ | 18:43 |
| smcginnis | Yes! | 18:44 |
| smcginnis | I 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 |
| smcginnis | I'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 |
| cdent | jroll I'm afrait that's not enough + you need a few more in order for me to hear you | 18:46 |
| jroll | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 18:46 |
| jroll | :D | 18:47 |
| cdent | now I hear you | 18:47 |
| jroll | cdent: I believe we have a specific "how do we reduce the number of patch sets per change" on the ironic ptg agenda | 18:48 |
| jroll | which I think is the main question matt is asking there | 18:48 |
| cdent | certainly an aspect thereof | 18:49 |
| persia | I feel that number of gerrit changes per large concept change is different than number of concept changes landed in $time | 18:53 |
| cdent | I 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 |
| smcginnis | ++ | 19:01 |
| dhellmann | cdent : I'm not finding a bookmark for an etherpad like that. Maybe we don't have one? | 19:11 |
| dhellmann | cdent : how about https://etherpad.openstack.org/p/PTG-Dublin-TC-topics | 19:12 |
| *** kong has quit IRC | 19:26 | |
| *** DuncanT has quit IRC | 19:26 | |
| *** kong has joined #openstack-tc | 19:27 | |
| cdent | dhellmann: thanks! | 19:28 |
| *** DuncanT has joined #openstack-tc | 19:30 | |
| cdent | Are there fewer CFP submissions than desired? Seems like the social media press is pretty loud? | 19:32 |
| *** lbragstad has joined #openstack-tc | 19:32 | |
| smcginnis | Oh how the turns have tabled. | 19:35 |
| *** diablo_rojo has quit IRC | 19:37 | |
| fungi | yeah, it depends on the culture of the review team to some extent | 19:48 |
| fungi | like 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 run | 19:49 |
| fungi | i like to think of collaborative development a bit like a musical jam session | 19:50 |
| smcginnis | I like that. | 19:50 |
| fungi | people have their own style, and they don't have to all become homogeneous clones to be able to create harmony | 19:51 |
| fungi | and 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 |
| fungi | can 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 from | 19:52 |
| *** ChanServ has quit IRC | 20:57 | |
| *** ChanServ has joined #openstack-tc | 21:30 | |
| *** barjavel.freenode.net sets mode: +o ChanServ | 21:30 | |
| *** diablo_rojo has joined #openstack-tc | 22:14 | |
| *** kumarmn has quit IRC | 22:16 | |
| cdent | fungi: 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 IRC | 22:51 | |
| jroll | code review is a words with colors jam session | 22:52 |
| fungi | collaborative scrabble | 23:00 |
| *** kektrain has joined #openstack-tc | 23:08 | |
| *** kektrain has left #openstack-tc | 23:08 | |
| *** kektrain__ has joined #openstack-tc | 23:23 | |
| *** kektrain__ has left #openstack-tc | 23:23 | |
| *** cdent has quit IRC | 23:25 | |
| *** hongbin has quit IRC | 23:26 | |
| *** kumarmn has joined #openstack-tc | 23:32 | |
| *** kumarmn has quit IRC | 23:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
