| openstackgerrit | Lingxian Kong proposed openstack/governance master: Qinling: Function as a Service in OpenStack https://review.openstack.org/533827 | 00:04 |
|---|---|---|
| *** kumarmn has joined #openstack-tc | 00:06 | |
| openstackgerrit | Lingxian Kong proposed openstack/governance master: Qinling: Function as a Service in OpenStack https://review.openstack.org/533827 | 00:07 |
| *** kumarmn has quit IRC | 00:07 | |
| *** kong has joined #openstack-tc | 00:24 | |
| *** kumarmn has joined #openstack-tc | 00:24 | |
| *** kumarmn has quit IRC | 00:28 | |
| *** kumarmn has joined #openstack-tc | 00:29 | |
| *** kumarmn has quit IRC | 00:30 | |
| fungi | that's mostly the position the infra team has taken on the matter in the past as well. we don't discourage people from running jobs. we do tend to zero in on disproportionate use of specific resources (usually not test node count but things like log archival) and try to help teams increase efficiency in their use of those resources | 00:43 |
| *** kumarmn has joined #openstack-tc | 00:47 | |
| *** liujiong has joined #openstack-tc | 01:10 | |
| *** kumarmn has quit IRC | 01:27 | |
| *** liujiong has quit IRC | 01:39 | |
| *** liujiong has joined #openstack-tc | 01:41 | |
| *** kumarmn has joined #openstack-tc | 03:21 | |
| *** kumarmn has quit IRC | 03:26 | |
| *** liujiong has quit IRC | 03:27 | |
| *** liujiong has joined #openstack-tc | 03:28 | |
| *** kumarmn has joined #openstack-tc | 03:40 | |
| *** liujiong has quit IRC | 03:55 | |
| *** liujiong has joined #openstack-tc | 03:56 | |
| *** rosmaita has quit IRC | 04:23 | |
| *** SamYaple has quit IRC | 04:24 | |
| *** SamYaple has joined #openstack-tc | 04:24 | |
| *** kumarmn has quit IRC | 04:29 | |
| *** liujiong has quit IRC | 06:45 | |
| *** liujiong has joined #openstack-tc | 06:46 | |
| openstackgerrit | Vasyl Saienko proposed openstack/governance master: Add networking-generic-switch-tempest-plugin under ironic https://review.openstack.org/534180 | 08:32 |
| ttx | Tracker updated @ https://wiki.openstack.org/wiki/Technical_Committee_Tracker | 08:49 |
| *** cdent has joined #openstack-tc | 08:49 | |
| openstackgerrit | Merged openstack/governance master: Remove the extra-atcs section for trove https://review.openstack.org/531860 | 08:56 |
| openstackgerrit | Merged openstack/governance master: show deliverables in the order listed in the projects file https://review.openstack.org/532977 | 08:56 |
| ttx | tc-members: office hour starts | 09:00 |
| cmurphy | hola | 09:00 |
| cdent | aw, beat me to it | 09:00 |
| cdent | :) | 09:00 |
| ttx | hehe | 09:00 |
| ttx | cdent: sorry you didn't make it to the Board. The election system is quite unfavorable and random | 09:00 |
| *** jpich has joined #openstack-tc | 09:00 | |
| cdent | "disappointed but not surprised" is my current state of mind | 09:01 |
| ttx | speaking of polls... | 09:01 |
| cdent | I agree that the election system is biased in various ways | 09:01 |
| ttx | what's the general feeling on the S poll ? mordred suggested to run it as a public poll | 09:01 |
| ttx | (on CIVS) | 09:01 |
| cdent | I think that would be fun and interesting in a way | 09:01 |
| cdent | there's no particular reason why it shouldn't be public | 09:02 |
| ttx | Historically we ran it on Launchpad, which was semi-public | 09:02 |
| cdent | but we'll need to protect against Sooty-McSootface | 09:02 |
| cdent | and variants | 09:02 |
| ttx | cdent: ballot stuffing is the only reason not to, but as mordred said risk is limited | 09:02 |
| ttx | we have safeguards in place already | 09:02 |
| ttx | basically we use the vote results as long as there is no good reason (legal, marketing) not to | 09:03 |
| ttx | "Stupid" for example would be legal but marketing could make a good case that it's hard to market | 09:04 |
| persia | If all the options have been chosen in such a way that any is acceptable, then ballot stuffing doesn't matter. To my mind, the best sort of election is one where it doesn't matter which is chosen, as one needs care less about ensuring the electorate makes the correct choice. | 09:04 |
| ttx | persia: the list includes everything that fits the criteria. The vetting hapepns after the vote to limit the legal cost of clearing names. | 09:05 |
| persia | ttx: Right, but from past polls, I had the impression that nearly any result would satisfy most of the polity (although some might grumble their favourite didn't win). If Legal/Marketing needs to move to second choice due to collision, I imagine folk would grumble but accept it, etc. | 09:06 |
| ttx | OK, I'll propose a couple wording changes to https://governance.openstack.org/tc/reference/release-naming.html | 09:06 |
| persia | This is vastly different from the sort of poll where if the electorate votes wrong, the head of government is expected to resign. | 09:07 |
| ttx | Anyone interested in coordinating that ? mordred was suggesting punting to election officials but we already put a lot on their plate | 09:08 |
| cdent | I'm simply too far behind on everything to take on another thing :( | 09:09 |
| * persia suggests calling for volunteers on the mailing list, as folk in this channel are a narrow bunch (and it's probably ideally not a current TC member) | 09:09 | |
| ttx | bah, I'll find someone -- it's a nice/easy opportunity for someone to step up | 09:09 |
| ttx | step 1 - wording change to allow public poll, 2- volunteer | 09:10 |
| ttx | cdent, cmurphy: any preferences in the goal list ? I think it's safe to say that the Storyboard one won't make it, but the other 3 are nice | 09:11 |
| cmurphy | I'm a fan of the mox one | 09:11 |
| cmurphy | having had to write mox tests for django-openstack-auth | 09:11 |
| cmurphy | not fun | 09:11 |
| ttx | yes that one is a good tech debt one | 09:12 |
| persia | On storyboard: while migrating in one cycle is unlikely, deferring past the point where the LP bug counter reaches 2000000 will cause issues with the current implementation. | 09:12 |
| ttx | the other 2 are more user-visible, so that makes a good mix | 09:12 |
| ttx | persia: i like dhellmann's idea of tracking the goals in SB, will force a bit of everyone to use it | 09:12 |
| * persia also | 09:12 | |
| ttx | that can't be more painful than the current system of tracking progress through governance changes | 09:13 |
| cdent | i think I prefer the pagination one to the upgrade one for reasons I'll write about on the upgrade one when I get around to reviewing them for real | 09:13 |
| ttx | would selecting all 3 be just too much ? | 09:14 |
| cmurphy | they are somewhat big goals | 09:15 |
| cmurphy | bigger than the two we have now | 09:15 |
| ttx | yeah | 09:16 |
| ttx | so maybe mox+pagination would be enough. The other two are likely to be selected for S, and I'd advise the work gets started during R | 09:18 |
| cdent | we could perhaps query the PTLs, see which they would prefer? | 09:22 |
| cdent | even if that is just adding them to the reviews | 09:22 |
| ttx | cdent: yes, that's the next step. Pre-select things that we think would make good candidates, present the list and ask feedback (not just to PTLs) | 09:22 |
| cdent | sure, but what I mean is that we're already at a small enough set to do that | 09:23 |
| ttx | I would present all except the SB one | 09:23 |
| cdent | we don't need to narrow further | 09:23 |
| ttx | the other 3 are doable and good | 09:23 |
| ttx | imho | 09:23 |
| persia | +1 on not narrowing: the SB one (and likely the upgrade one) are better removed in ML discussion from the larger list, so everyone has context about why. | 09:23 |
| ttx | so it's more a question of urgency and work capacity | 09:23 |
| persia | To my mind, the main reason for presenting the SB one (and then immediately arguing against) is that it was posted as the only suggested goal for some time, so many folk are aware it was nominated. | 09:24 |
| ttx | ok. I' | 09:24 |
| ttx | I'll coordinate with EmilienM so that something RFC is sent to the list presenting the goals and giving a bit of context | 09:25 |
| ttx | In other news, Qinling was proposed for addition to the Rocky cycle | 09:27 |
| cdent | vaguely related to that: have we considered what the impact of the expanded foundation focus (kata, etc.) has on project applying to be official? Do we know when/if we should be pointing applicants elsewhere in the foundation? | 09:30 |
| ttx | cdent: yes. I expect some things that were traditionally proposed for "OpenStack" because that was the only thing to now be proposed elsewhere | 09:36 |
| ttx | The canonical example being Stackube | 09:36 |
| ttx | which, while related to openStack, was clearly not OpenStack | 09:36 |
| ttx | but more of a Kubernetes distribution glue to run on top of openstack components | 09:37 |
| cdent | Is "uses keystone" a reasonable proxy for "being OpenStack"? I sometimes think it is, and other times think it is too broad. | 09:37 |
| ttx | I generally think it's too broad. | 09:38 |
| cdent | In general I think if we have friendly places to direct people, we should be more rigorous in our vetting | 09:38 |
| ttx | yes | 09:38 |
| ttx | In particular we tolerated a number of "adjacent technology enablers" to be developed as a part of openstack, while it's clearly gateways to other systems | 09:39 |
| ttx | and imho would benefit from being seen as "on top of" openstack | 09:39 |
| ttx | everything that reuses openstack components should not be called openstack imho | 09:40 |
| ttx | open infrastructure can be build from Kuberenetes bits and openstack bits | 09:40 |
| ttx | So if the "container infrastructure" strategic focus area picks up, I would recommend Stackube to be added there | 09:41 |
| ttx | + maybe Kuryr/Fuxi | 09:41 |
| ttx | moved there | 09:41 |
| ttx | as those are the same things: enabling container/k8s-centric deployments to make use of isolated openstack components | 09:42 |
| cmurphy | what's the defining line between openstack and not openstack? | 09:42 |
| cmurphy | it's not clear to me why containery things are not openstack | 09:42 |
| ttx | We had that discussion when Tacker was proposed. It was clearly a thing that was built on top of openstack, to translate it into NFV-compatible bits | 09:43 |
| ttx | That was a close vote to accept them | 09:43 |
| ttx | cmurphy: I like to think that the map helps (https://www.openstack.org/openstack-map) | 09:46 |
| ttx | Some people deploy "openstack the product" and are all-in. Some others just reuse openstack components in a larger stack. We need to enable both | 09:46 |
| ttx | The part in the map that does not follow this product approach much is the "OPENSTACK-ADJACENTENABLERS" bucket | 09:47 |
| ttx | They are part of the picture because they don't have a better place to go | 09:48 |
| ttx | But I think everything else "fits" | 09:48 |
| ttx | We might want to be more picky as we move up and sideways, things really have to provide extra value to be included in the "product" | 09:49 |
| ttx | since they extend it a bit | 09:50 |
| ttx | To answer cdent's original question, yes the addition of new strategic focus areas give us the opportunity to have a bit more of a product approach in our definition of what falls in the openstack bucket. | 09:51 |
| ttx | Rather than our traditional "whatever we produce as a community" big-tent response | 09:52 |
| cmurphy | we sort of need a new resolution then, don't we? | 09:52 |
| ttx | It's a bit early in the process to have a definitive answer, but that's definitely something for us to work on in 2018 | 09:53 |
| ttx | Separating the infra into its own "product of our community" will also clarify what "openstack" is | 09:53 |
| ttx | because you will notice that the map conveniently ignores it, but it's still currently a part of "openstack" | 09:54 |
| ttx | I like to think of openstack in terms of commonality between components too | 09:55 |
| ttx | basically "an openstack service" (generally) means a number of libraries being used, API guidelines etc | 09:56 |
| ttx | Interestingly, it also still means Python | 09:58 |
| ttx | (at least in that central "openstack" bucket on the map | 09:59 |
| cmurphy | right | 09:59 |
| cmurphy | I would like to avoid some scenario where the deployment tools get kicked out :) | 09:59 |
| ttx | With the reduction in resources we observed in 2017, sharing more practices between components sounds like a good idea | 10:00 |
| ttx | cmurphy: The only part of the map that feels "artificially in" to me is the adjacent enablers bucket | 10:01 |
| persia | Just take care not to reduce the set of things so much that it drives additional resource constraints. | 10:01 |
| ttx | we need client tools, we need operational addons, and we need deployment/lifecycle management tools. | 10:01 |
| ttx | They are part of "the product" even if they are not technically user-facing cloud services | 10:02 |
| ttx | persia: right | 10:02 |
| ttx | focus is a double-edged sword | 10:03 |
| cmurphy | with Qinling that seems like it would fall into the workload provisioning bucket I think? | 10:05 |
| ttx | I have to do a deeper look, especially looking at dependencies. It could be seen as a form of compute too | 10:06 |
| ttx | That subdivision inside the main bucket is really marketing | 10:06 |
| ttx | like where Zun is placed, could have gone in worload provisioning too | 10:06 |
| cmurphy | hmm | 10:06 |
| ttx | as AWS and others promote containers and functions as primary compute resources, it /could/ go in the compute box | 10:07 |
| ttx | is it a raw resource, or is it a form of orchestration, or is it a specific workload ? | 10:08 |
| ttx | If you look at how most public clouds market it, it's really a raw resource. "Serverless" ! | 10:08 |
| ttx | But I'm making things up, I really need to dive into it to see if it is what I think it is :) | 10:09 |
| cmurphy | :) | 10:10 |
| cdent | at the level of technical development of openstack should we be letting marketing drive our grouping decisions, especially when the containing foundation has changed shape. This feels like it could be an opportunity to foist off the marketing decisions elsewhere and limit the numbrer of factors we need to concern ourselves with. (Not sure that would be a good idea, just riffing) | 10:12 |
| persia | Despite my general preference for "serve the ones that come", allowing marketing to drive that seems sensible at this point. There is a fairly active marketing mailing list, which could likely be convinced to take authoritative decisions on some matters. | 10:14 |
| ttx | well, the "map" is an (opinionated) product of the Foundation at this point | 10:14 |
| ttx | so we as TC can definitely give input and complain about weird choices | 10:15 |
| persia | But whether a project is a good *technical* fit as "official openstack" is something for which they are unlikely to be able to render an opinion. | 10:15 |
| ttx | but it's not a duty of ours to keep it up to date | 10:15 |
| ttx | it's just hard for everyone to agree on where things should go and how they shall be named. That's where the editorial choice comes in | 10:17 |
| ttx | (I personally hate the "Core functionality" bolding but it's not 100% my decision) | 10:17 |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Allow public polling to choose release names https://review.openstack.org/534226 | 10:24 |
| *** kumarmn has joined #openstack-tc | 10:34 | |
| *** kumarmn has quit IRC | 10:38 | |
| *** gcb has joined #openstack-tc | 10:46 | |
| *** liujiong has quit IRC | 10:56 | |
| *** dtantsur|afk is now known as dtantsur | 11:00 | |
| *** kumarmn has joined #openstack-tc | 12:35 | |
| *** kumarmn has quit IRC | 12:40 | |
| *** kumarmn has joined #openstack-tc | 13:01 | |
| dhellmann | ttx, tc-members: regarding the goals discussion, I've heard from one or two projects that they'd like a little more space to work on their existing priorities this cycle. Maybe we only want to adopt one goal? | 13:05 |
| *** kumarmn has quit IRC | 13:06 | |
| *** dtantsur is now known as dtantsur|brb | 13:17 | |
| *** rosmaita has joined #openstack-tc | 13:24 | |
| ttx | dhellmann: I'd say that's the discussion we need to have on the ML. Maybe those one/two projects could end up being not impacted by one of the goal we select | 13:32 |
| dhellmann | that sounds like a good approach | 13:34 |
| rosmaita | ttx dhellmann sorry i missed tc office hours, will try to make tomorrow ... but this cycle included a hidden community goal, viz., zull3 migration that has eaten up a lot of my time trying to restore functional gates | 13:42 |
| rosmaita | so i feel like we already had 3 this cycle | 13:42 |
| rosmaita | i woudl be in favor of at most 1 next cycle | 13:42 |
| rosmaita | ideally, zero | 13:43 |
| rosmaita | though i understand that might send the wrong message | 13:43 |
| ttx | rosmaita: that's good input. we'll do a ML thread soon to discuss how many / which with the wider community, be sure to chime in | 13:46 |
| rosmaita | ttx: will do, is it too late to propose a goal for R? | 13:50 |
| dhellmann | rosmaita : 3? I thought we only had 2? did glance need to address both of those? | 13:53 |
| *** kumarmn has joined #openstack-tc | 13:56 | |
| cmurphy | I think the third was the "hidden" zuul migration goal | 13:57 |
| persia | Maybe it makes sense to ask the infra folk explicitly if there are any significant infra goals this cycle that might impact other projects. | 13:58 |
| persia | Probably the same for interop, etc. Essentially any group whose goals would inherently affect large proportions of the total set of project teams. | 13:59 |
| dhellmann | cmurphy : ah, yes, that one caught me by surprise | 14:03 |
| dhellmann | persia : good idea | 14:03 |
| rosmaita | i should make it clear that the infra team has done a great job with the zuul3 migration and put in a lot of work to make it smooth, but this being glance, there have been some weird issues that came up and are taking up time to figure out & fix | 14:04 |
| persia | Oh, I've also been impressed with the infra (and specifically zuul) team's efforts to help: I just thought it would be nice to try to provide wider warning (perhaps through community goals) in the future. | 14:05 |
| rosmaita | persia you are entirely correct, that wasn't a response to your comment | 14:06 |
| dhellmann | that's a good point. the zuulv3 migration could have been orchestrated as a community goal. | 14:07 |
| rosmaita | maybe we can make it a retroactive goal | 14:07 |
| rosmaita | :) | 14:07 |
| dhellmann | I suspect if it had been proposed for this cycle I would have objected to it on the grounds that there was insufficient documentation for anyone not involved with writing zuul to help with the migration. Though that could have been fixed up front and we might still have done it. | 14:09 |
| mordred | the zuul v3 rollout provided many lessons and I hope to never do anything like it ever again | 14:10 |
| * dhellmann nods | 14:10 | |
| *** dtantsur|brb is now known as dtantsur | 14:18 | |
| *** david-lyle has quit IRC | 14:33 | |
| EmilienM | hi | 14:39 |
| *** hongbin has joined #openstack-tc | 14:39 | |
| EmilienM | dhellmann: it's good feedback but these projects should raise it on the ML (like ttx said) | 14:39 |
| dhellmann | well, we need to take the feedback where we get it. Not everyone is comfortable "going against the grain" in a big public discussion. | 14:44 |
| dhellmann | especially when the conclusion that there will be goals seems predetermined | 14:44 |
| smcginnis | Really good points about the zuul migration. I think that was a bigger effort than anyone realized going in to it, and it ended up consuming much more time from products than we would have thought. | 14:46 |
| fungi | i think it was a really big effort, but i don't think any of us were deluding ourselves as to whether we could accurately guess the scope. we knew it was necessary and we knew there would be significant impact. we also knew that we wouldn't be able to quantify the impact but that hardly matters if it's something that has to get done regardless | 14:53 |
| smcginnis | I agree. To clarify somewhat - I don't think other projects understood the impact it was going to have. Each project had to get much more engaged and do much more work than what I think was expected. | 14:54 |
| fungi | we also knew it put the infra team at considerable risk of being tarred and compressed^Wfeathered, but without a significant overhaul in our ci paradigm we wouldn't have been able to continue to scale to meet future demands of the community | 14:54 |
| fungi | and delaying the inevitable would only have worsened the impact | 14:55 |
| fungi | i also think it ended up being a good choice to roll up a bunch of significant breaking changes together rather than trickle them into the community in dribs and drabs over the course of the next several years | 14:56 |
| fungi | but yes, i agree it ended up being similar in nature to a community-wide goal with notable impact to pretty much every team/deliverable | 14:57 |
| fungi | though i don't know if we could have sufficiently scoped it as a community-wide goal under the present governance framework | 14:58 |
| cdent | I think it went remarkably well, all things considered, and there would have been no way to predict "the right way" | 14:58 |
| dhellmann | fungi : sure. all of those are good points. I think the thing that was missing was really clearly communicating some of that uncertainty. Following the goal structure may have helped, if only because of the structure itself. | 14:58 |
| cdent | any way would have been painful | 14:58 |
| ttx | EmilienM: ICYMI in the backlog, in the morning we discussed goals and think we have enough goals proposed at this point. We should start the public ML discussion on which / how many. I assume you will start it (if you can't let me know and I'll pick up the task) | 14:58 |
| EmilienM | ttx: i'll do it today | 14:59 |
| ttx | EmilienM: thanks! | 14:59 |
| fungi | dhellmann: it may have, yes, though really with as many unknowns as there were (and even still are this far into it) it's hard to know when a particular deliverable has reached full parity with the jobs it had before we started | 15:04 |
| fungi | there's a long tail on it which may never reach 100% completion everywhere as old approaches get abandoned in parallel with jobs being fixed and/or rewritten | 15:05 |
| fungi | whereas we can say that we're "mostly there" with the community as a whole being close to business as usual again | 15:06 |
| dhellmann | fungi: sure. as I said, I probably would have pushed to have more documentation written up front to help with the job ports to remove some of the uncertainty. and we probably would have wanted to phase it in (move projects from v2 to v3 running in parallel) though I'm sure that would have taken more effort. | 15:07 |
| pabelanger | I also sure it is the first time people are getting exposure to ansible too, which might not have helped keep things smooth | 15:22 |
| fungi | the documentation ended up needing to be retrospective in many ways anyway, since there were still a lot of unknowns going into it. if we'd pre-written much of that we would probably have ended up needing to rewrite almost all of it anyway based on things we learned during actual implementation which we never would have predicted | 15:24 |
| fungi | the biggest challenge is that we had provided a turing-complete framework for projects to use to define their jobs, and needed to move them all to a different turing-complete framework. a bunch of that was automatable but the body of configuration (some 20k jobs) so vast that we couldn't hope to even classify most of the corner cases | 15:25 |
| fungi | we're still finding new ones in infrequently-run jobs, even months later | 15:26 |
| dhellmann | fungi : well, I'm still not finding helpful docs on what variables zuul defines so I know what I can use in job definitions and it's hard to find even what jobs exist already to use as bases because they're spread across several repos. That's the sort of thing I mean it would have been useful to have. | 15:31 |
| dhellmann | I don't discount the complexity of the change at all. It was difficult to help, though, because I didn't have enough detailed info. I'm still struggling with that (see the ongoing discussion in -infra) | 15:32 |
| dhellmann | pabelanger : also a good point. | 15:32 |
| fungi | yup, i agree it's something i struggle with too (knowing what variables zuul provides via ansible is only half the problem, knowing what variables ansible itself provides is at times a challenge to figure out as well since we didn't write it) | 15:34 |
| persia | Ansible is sufficiently complex that determining variable settings is difficult even for folk that did write it. This isn't a critique of ansible, but just the nature of very complex systems. | 15:35 |
| EmilienM | ttx, cmurphy, cdent: while mox+pagination are good goals, they don't directly help operator's life, while upgrade goal would do. | 15:46 |
| ttx | EmilienM: right. pagination is more end-user-facing | 15:47 |
| ttx | and mox is more tech debt reduction | 15:47 |
| ttx | which is why I like all 3 | 15:48 |
| ttx | :) | 15:48 |
| EmilienM | ttx: i'm still reading backlog :) | 15:48 |
| ttx | on the plus side, the upgrade goal would not affect glance :) | 15:48 |
| *** david-lyle has joined #openstack-tc | 15:49 | |
| dhellmann | would the pagination goal affect glance? | 16:08 |
| dhellmann | or mox? | 16:08 |
| dhellmann | the mox one doesn't seem to (I don't see mox in the glance dependencies) | 16:08 |
| persia | rosmaita ? | 16:08 |
| dhellmann | although having 3 goals seems like a stretch | 16:09 |
| rosmaita | persia: reading scrollback | 16:09 |
| persia | rosmaita: Mostly about dhellmann's immediate questions. | 16:10 |
| dhellmann | rosmaita : I was trying to get a sense of which of the goals affect you | 16:10 |
| dhellmann | *proposed goals | 16:10 |
| rosmaita | dhellmann i think we are ok on pagination, someone did a project a while back to get rid of mox, but we still have some usage, so i think only the hardest ones are left, which is good or bad depending on how you look at it | 16:20 |
| dhellmann | yeah | 16:20 |
| rosmaita | dhellmann it's probably used in glanceclient or glance_store | 16:20 |
| dhellmann | I would have worried if we had 3 things we wanted you to do | 16:20 |
| dhellmann | 1 seems ok | 16:20 |
| rosmaita | well, except we still haven't completed py35 and policies is looking iffy | 16:21 |
| rosmaita | so i am worried about backlog | 16:21 |
| dhellmann | sure | 16:21 |
| dhellmann | it would be good to raise those concerns on the ML so we can try to find you some help | 16:22 |
| rosmaita | that is a good point | 16:22 |
| EmilienM | ttx: update sent. | 16:29 |
| *** kumarmn has quit IRC | 17:09 | |
| *** kumarmn has joined #openstack-tc | 17:21 | |
| *** kumarmn_ has joined #openstack-tc | 17:22 | |
| *** kumarmn has quit IRC | 17:26 | |
| *** jpich has quit IRC | 17:30 | |
| *** openstackgerrit has quit IRC | 17:33 | |
| *** dtantsur is now known as dtantsur|afk | 18:05 | |
| *** david-lyle has quit IRC | 18:08 | |
| *** david-lyle has joined #openstack-tc | 18:59 | |
| *** diablo_rojo has quit IRC | 19:05 | |
| *** diablo_rojo has joined #openstack-tc | 19:21 | |
| *** cdent has quit IRC | 19:24 | |
| *** harlowja has joined #openstack-tc | 19:44 | |
| *** david-lyle has quit IRC | 19:57 | |
| *** david-lyle has joined #openstack-tc | 19:57 | |
| *** david-lyle has quit IRC | 21:12 | |
| *** david-lyle has joined #openstack-tc | 21:23 | |
| *** diablo_rojo has quit IRC | 21:27 | |
| *** diablo_rojo has joined #openstack-tc | 21:27 | |
| *** openstackgerrit has joined #openstack-tc | 21:31 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: update the goal process to use storyboard for tracking https://review.openstack.org/534443 | 21:31 |
| *** jroll has quit IRC | 22:53 | |
| *** jroll has joined #openstack-tc | 22:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!