20:04:26 <ttx> #startmeeting tc
20:04:27 <openstack> Meeting started Tue Jan 20 20:04:26 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:04:28 <ttx> sorry for the delay
20:04:28 * dhellmann knew he could do it
20:04:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:04:30 <ttx> Our agenda for today:
20:04:31 <openstack> The meeting name has been set to 'tc'
20:04:36 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:04:48 <ttx> zehicle: you around?
20:05:10 <zehicle> yy
20:05:12 <ttx> #topic Next Defcore steps (zehicle)
20:05:26 <ttx> zehicle: looks like we have amendments passed?
20:05:29 <zehicle> Yeah!  The bylaws changed :)
20:05:34 <ttx> so what's up?
20:05:48 <zehicle> so, they said that we would have a process to change the core
20:05:59 <zehicle> and that process would be approved by the TC and Board before it could be implmented
20:06:04 <jokke_> o/
20:06:15 <zehicle> so, DefCore is working to write that stuff down in a process-y way
20:06:27 <zehicle> and then bring it back to TC and Board for more discussion
20:06:47 <zehicle> I was hoping that we'd have some official TC delegates to work w/ DefCore on that definition
20:06:50 <ttx> zehicle: that's the process to communicate changes in "TC approved releases" right
20:06:58 <vishy> o/
20:07:09 <zehicle> yes
20:07:14 <ttx> like make sure we don't remove stuff from it without a lot of advance notice
20:07:20 <zehicle> +1
20:07:39 <ttx> zehicle: One interesting twist to the tags stuff is that we would express those "Tc-approved releases" using a tag
20:07:41 <zehicle> the primary artifacts are JSON files with the capabilities and sections
20:07:54 <ttx> rather than with the blanket "integrated release" thing
20:07:57 <zehicle> possibly - was not trying to work out the details of how just yet
20:08:06 <zaneb> we need to hook everyone up to electrodes that shock them every time they say 'core' on IRC ;)
20:08:09 <ttx> so we can probably align the requirements with that tag definition
20:08:18 <zehicle> not sure there's enough power
20:08:19 <mordred> yah - I think the ask is "who from the TC wants to dive in on the definition?"
20:08:32 <zehicle> mordred, yes
20:08:50 * mikal backs away
20:08:55 <ttx> Is anyone interested in participating to that ?
20:08:55 <mordred> it's possible that there are process elements that have important ramifications based on current or new TC process - but those details would be worked out by this group, yeah?
20:08:56 <zehicle> I'm happy to discuss more details here too, but having butts in seats is first
20:09:14 <mordred> I would be happy to participate - but my track record in being able to show up at defcore meetings is very low
20:09:15 <ttx> I can try -- usually the time of the meetings is a bit EU-unfriendly but I'm fine helping out
20:09:19 <mikal> Would it make sense to trick one of the people on the board and TC into working on that?
20:09:33 <zehicle> If I know who's in, then we'll adjust timing
20:09:37 <annegentle> and by trick you mean...
20:09:45 <mikal> I was thinking russellb would enjoy this
20:09:47 <ttx> yay, our BoD+TC members would make ideal candidates
20:09:56 <ttx> (that would be russellb, vishy and mordred)
20:10:23 <zehicle> only if they have the time to put into it
20:10:23 <russellb> sure
20:10:54 <zehicle> not likely to be crazy work, but we do need someone who can help with the workflow that works well with the community process
20:10:57 <ttx> how about russellb and mordred as main correspondants + ttx as a backup
20:11:03 <mordred> kk
20:11:04 <russellb> wfm
20:11:08 <mordred> although I cannot attend this friday
20:11:20 <ttx> I'm happy to leave the seat to anyone though, so feel free to steal it :)
20:11:21 <mordred> or whichever the day is that zehicle is doodling for
20:11:41 <zehicle> mordred, that's ok.  we'll set the agenda and discuss
20:11:47 <ttx> zehicle: anything else ?
20:11:55 <zehicle> two smaller items
20:12:15 <zehicle> 1) we are considering moving the capabilities/secitons JSON out of refstack and looking for recommendations.
20:12:15 <ttx> #info Defcore Board/TC co-approved process design: russellb and mordred as main correspondants + ttx as a backup
20:12:37 <zehicle> that will be part of the DefCore disucssion.  no need to resolve now.  Just letting everyone know it will be discussed
20:12:53 <ttx> zehicle: who has final approval on that ? Board ?
20:12:58 <zehicle> 2) making sure there's visibility on RefStack / TestIDs / Tempest interactions
20:13:08 <zehicle> ttx, TC first and then Board
20:13:16 <zehicle> that was my reading of the bylaws changes
20:13:33 <zehicle> I am thinking it makes sense to put it on the Joint agenda for May in Vancouver and do it together
20:13:38 <ttx> ok
20:14:22 <zehicle> so #2, the process really needs to tests identities to be stable across releases - so it's important to have GUIDs for tests
20:15:03 <zehicle> I know that's more Tempest team, but there are cross project impacts so I wanted to make sure it was on the TC radar
20:15:30 <ttx> zehicle: could you describe the impacts in some ML post ?
20:15:44 <ttx> so that we can start thinking about that ?
20:15:51 <zehicle> sure. O
20:16:01 <zehicle> there's a patch out there, I'll send the link
20:16:08 <sdague> there was a session in Paris on it as well, the current progress is - https://review.openstack.org/#/c/144329/2/specs/meta-data-and-uuid-for-tests.rst,cm this spec proposal
20:16:17 <zehicle> sdague, thanks.  yes
20:16:25 <ttx> #action zehicle to introduce refstack/tempest needs impact in a ML post to discuss in a subsequent meeting
20:16:47 <ttx> zehicle: anything else ?
20:16:58 <zehicle> that's the main items for me
20:17:08 <zehicle> timing is tight to get this done before Vancouver
20:17:08 <ttx> zehicle: alright! Thanks for coming
20:17:11 <zehicle> :)
20:17:21 <ttx> no kidding
20:17:31 <annegentle> thanks zehicle
20:17:33 <ttx> #topic Project structure reform
20:17:42 <ttx> * Template for tags definition (https://review.openstack.org/145734)
20:17:48 <ttx> This one now has hte required votes, so I'll approve it right now
20:17:59 <ttx> checking for any recent -1
20:18:03 <devananda> ttx: it looks like it was updated without addressing comments on the last rev?
20:18:40 <devananda> ttx: was that intentional? to be clear, I think the current wording is good, though I thought it could use a little more
20:18:50 <ttx> devananda: no, I just missed it
20:18:55 <devananda> I can toss that up in a follow on ...
20:19:01 <devananda> no need to hold this up
20:19:02 <ttx> devananda: How about we propose those as subsequent chnages ?
20:19:06 <ttx> ok
20:19:36 <ttx> I'll approve it now, we can add examples as a subsequent change
20:20:10 <sarob> Ttx: examples will be good
20:20:27 <ttx> FWIW I expec tthe tag template to evolve as we define more of those
20:20:39 <ttx> * Definition of the initial 'integrated-release' tag
20:20:56 <sarob> Ttx: I should have PM feedback next Monday
20:21:12 <ttx> This one has 8 votes, ready to approve unless someone objects
20:22:15 <ttx> I'll take that as a "no obejction"
20:22:28 <ttx> On tag application (https://review.openstack.org/146818) last week we discussed a format that would allow a payload / reference
20:22:44 <ttx> Something like: 'integrated-release: bexar'
20:22:51 <ttx> Feel free to suggest on the review other ways to store extra information -- if you don't I'll try to find something
20:23:10 <dhellmann> I like eglynn's proposal of using a dictionary or sub-dictionary
20:23:16 <jeblair> ++
20:23:40 <jeblair> (ime that works really well in yaml)
20:23:42 <ttx> reading now, missed it earlier
20:23:45 <devananda> ++
20:23:48 <annegentle> so tags are applied in programs.yaml?
20:24:02 <dhellmann> annegentle: right
20:24:05 <jeblair> heh, i guess it should be 'mv'd to projects.yaml :)
20:24:18 <dhellmann> ttx: I have some time on a plane this week, so if we can settle on a format I can work on some code to render tables
20:24:18 <ttx> it is moved
20:24:23 <ttx> in the next review
20:24:39 <annegentle> and you're renaming it right :) heh jeblair types faster than I
20:24:51 <ttx> hmm, ok, I'll try to post a new rev with the dict model soon
20:25:02 <mordred> annegentle: jeblair types faster than everyone
20:25:08 <annegentle> mordred: noted
20:25:26 <ttx> jeblair: I suspect we need to define the dictionary in the tag definition too
20:25:33 <dhellmann> ttx: ++
20:25:44 <dhellmann> either there, or in another yaml file (that would make validation easier)
20:25:49 <jeblair> ttx: agreed
20:25:51 <ttx> so maybe that can be proposed as a tag template evolution and be retrofit in the just-approved integrated-release tag
20:26:09 <ttx> I should probably have held on approval, oh well
20:26:34 <russellb> this won't be the only thing we need to tweak as we go
20:26:35 <russellb> no big deal
20:26:51 <ttx> Yes I'd rather make progress and fix thatn hold on forever
20:27:26 <ttx> #action ttx to propose the version with dictionary, unless someone beats him to it
20:27:37 <ttx> * Move from program-based structure to project-based (including new projects requirements) (https://review.openstack.org/145740)
20:27:42 <annegentle> I'd like tags defined elsewhere to not overload projects.yaml (nee programs.yaml)
20:27:45 * ttx chekcs for recent reviews
20:27:56 <annegentle> I had questions on that
20:28:10 <annegentle> that would probably be easiest to discuss here
20:28:21 <ttx> annegentle: you would duplicate the list of projects if it was in a separate file
20:29:09 <ttx> On the 145740 one, I posted a new rev clarifying the "logged IRC meetings" requirement.
20:29:10 <annegentle> ttx: I guess a document explaining the tags would meet my need
20:29:22 <ttx> Still waiting on more reviews to make progress here
20:29:23 <dhellmann> ttx: I took that to mean the fields expected for each tag, not the associations of the tags with the projects
20:29:29 <ttx> dhellmann: reading your recent comment
20:29:54 <ttx> dhellmann: that would belong to the tag definition document, no ?
20:30:05 <annegentle> so are tags applied to projects or repos?
20:30:10 <ttx> to repos
20:30:15 <dhellmann> ttx: I thought that's what annegentle was saying, but maybe I misread
20:30:24 <annegentle> so... why maintain tags on projects?
20:30:37 <annegentle> not all of the docs repos are going to be in the docs project I imagine
20:30:38 <ttx> well, projects is a bit overloaded
20:30:47 <ttx> project teams on one side, repositories on the other
20:30:54 <annegentle> so I'm thinking through it that way.
20:31:04 <ttx> you describe project teams and the list of their repositories
20:31:21 <annegentle> for example, the security team owns the security-doc repo, do they get added to projects.yaml in order to be tagged?
20:31:21 <ttx> annegentle: take Nova as an example
20:31:37 <ttx> Nova is the project team, openstack/nova and openstack/python-novaclient are repositories
20:31:41 <annegentle> then do my example :)
20:31:49 <ttx> Only openstack/nova would get the compute-base tag if we define such thing
20:31:53 <dhellmann> annegentle: I would expect so, yes.
20:32:06 <annegentle> so does the security team need to elect a ptl?
20:32:12 <ttx> annegentle: they already do
20:32:24 <annegentle> but they're not in programs.yaml now right
20:32:45 <ttx> annegentle: it's a bit of a corner case -- the securityt-doc repo was sponsored by the docs team
20:32:56 <dhellmann> perhaps that's an oversight?
20:32:59 <annegentle> but no longer in the new era I am supposing
20:33:01 <ttx> so technically it belongs to docs currently
20:33:12 <ttx> in the new era, it would be easier to let them be a team
20:33:17 <ttx> and let them own that repo
20:33:19 <annegentle> I sense the same
20:33:34 <ttx> as long as we agree they fit the requirements
20:33:56 <ttx> requirements we are currently defining :)
20:34:02 <annegentle> how does a cross project ptl then choose what to tag as "supported?"
20:34:14 <annegentle> seems heavy on individual ptl
20:34:46 <ttx> annegentle: not sure I understand the question
20:34:54 <ttx> annegentle: the team should suppor what it's fine supporting ?
20:35:18 <ttx> dhellmann: thanks for the feedback, that's the kind of stuff I need before I make up the next rev
20:35:32 <annegentle> okay that'll still have the ptl deciding L2 L3 and so on for neturon, right/
20:35:33 <dhellmann> I thought we were avoiding "supported" tags -- cross-projects teams need to be willing to "support" everything, even if they don't do the work directly
20:35:35 <devananda> annegentle: why would doc repos not be in the doc project?
20:35:42 <ttx> other members: if you feel something is missing or out of place, feel free to suggest it changed in the review
20:35:52 <devananda> annegentle: and still have a doc-team-applied tag, i mean
20:36:15 <ttx> dhellmann: yes, "supported" might not be the best term for it
20:36:20 <annegentle> devananda: currently there are repos that are not directly supported by the doc team, like training is "incubating" somewhat in the doc programs.yaml
20:36:20 <dhellmann> ok
20:36:37 <annegentle> Ok I'll note "let's not say supported" in the review where it's relevant
20:36:41 <ttx> We support everyone, we directly handle a subset
20:37:04 <devananda> ttx: I believe we've used the word "supported" in the past to mean directly-handled
20:37:11 <annegentle> "you belong on docs.openstack.org, do the work to get there" is more what I'm thinking?
20:37:32 <dhellmann> annegentle: so that would be a "published to docs.openstack.org" tag? That seems like a good one.
20:37:41 <annegentle> dhellmann: right I think that's the heart/root of it
20:37:43 <fungi> this sounds more along the lines of the "production ready" tag discussion
20:37:58 <devananda> perhaps a generic "supported-by-<teamname>" tag type is helpful here?
20:38:06 <fungi> (but with a docs twist)
20:38:06 <devananda> or are we solving a problem that doesn't really exist
20:38:08 <dhellmann> annegentle: although I'd hope under this new structure everyone "belonged" there :-)
20:38:17 <ttx> yeah, I think we can cross that bridge when the first of such tags will be proposed
20:38:34 <ttx> it will likely set policy for most of them
20:38:34 <devananda> is it meaningful to anyone outside of the TC and PTLs to know which team is writing which docs?
20:38:36 <sdague> devananda: I'm not sure that's a problem that exists, because at least for me the envisioned consumers of these are deployers
20:38:41 <devananda> or who is writing what client?
20:38:46 <sdague> it should be deployer / user relevant info
20:38:50 <annegentle> dhellmann: it is a big tent but people have to do the work is all I'm trying to indicate. Then it feels like "earn the tag" and then we're back to subjective unless we can test doc coverage automatically.
20:38:51 <devananda> sdague: right
20:38:52 <ttx> sdague: ++
20:39:06 <devananda> so which team wrote the docs in this repo is irrelevant to them
20:39:09 <dhellmann> annegentle: right, not everyone is "ready" but everyone should be "invited"
20:39:19 <devananda> ditto for python clients
20:39:43 <sdague> devananda: yeh, but a url to their user manual, install guide, developers guide are all relevant
20:39:45 <ttx> I think we can save that discussion for when we'll propose such a tag, like in a few meetings
20:39:55 <ttx> we have more topics to cover
20:40:01 <devananda> ttx: ack
20:40:12 <ttx> Please post your comments on the proposed requirements though, I'd like to get to a more precise proposal next week
20:40:29 <annegentle> tags can be used by: contributor developers (what should I work on?), operators (what should I run in production?), users and app devs (what does my cloud provider offer that's OpenStacky?) and yep I'll summarize in a review
20:40:34 <ttx> and I know there is no concsensus on some of those (like the oslo requirement Doug just proposed added)
20:41:12 <ttx> #topic Adding python clients to global requirements (boris42)
20:41:25 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054275.html
20:41:31 <ttx> do we have boris42 around?
20:41:41 <haypo> boris-42: ping
20:42:07 <ttx> It feels like projects.txt is used for two purposes: tracking integrated release deps and converging deps across projects
20:42:17 <ttx> and some tension results from that
20:42:19 <haypo> ttx: (boris-42 is idle since 1 hour according to my IRC client)
20:42:21 <sdague> ttx: agreed
20:42:23 <mordred> yah
20:42:27 <devananda> ttx: yes. I've hit that before as well
20:42:34 <ttx> I mean, deps convergence is a noble goal
20:42:39 <devananda> the original goal AIUI was only #2
20:42:52 <devananda> ensuring that all the projects could be installed in one environment
20:43:07 <devananda> though I think mordred had another idea how we could address that
20:43:09 <mordred> fwiw - I don't have a problem with the theory of doing that with the noble goal of convergence - but I do worry about adding more things that have non-managed transitive deps that could get into conflict
20:43:09 <sdague> devananda: it was also keeping sanity on what that was
20:43:12 <devananda> with an install-everythihng job
20:43:12 <ttx> devananda: how sustainable is that in a world where more projects exist ?
20:43:27 <devananda> wich would let us get away from using requirements.txt to fulfil that goal
20:43:33 <devananda> and let it become #1
20:43:53 <dhellmann> devananda: except the integrated release is going away, so do we care about #1 any more?
20:43:57 <clarkb> so I don't think it should be #1 at all
20:44:07 <clarkb> you track individual project deps in the project requirements lists
20:44:13 <devananda> dhellmann: we still care that certain things can be installed together
20:44:20 <mordred> I agree - I think it's about #2 - ensuring side-by-side ability
20:44:21 <clarkb> then global reqs is a sanity check for things that want to be openstacky
20:44:33 <devananda> clarkb: individual project deps are bound by global requirements
20:44:34 <dhellmann> devananda: certainly, but that's not going to be limited to the integrated release
20:44:39 <clarkb> dhellmann: yes
20:44:41 <mordred> it's just that it turns out it's SO MUCH HARDER than we thought
20:44:46 <clarkb> er devananda yes
20:44:48 <devananda> clarkb: that is the problem which I thihnk boris is trying to solve
20:44:48 <mordred> even just in the integrated release
20:44:53 <ttx> would we track common deps for "whatever gets gate-tested together" separately from "general deps convergence in openstack projects" ?
20:44:55 <sdague> well, part of the practical challenge is this is kind of an n^2 problem
20:45:00 <clarkb> devananda: I don'tthink it is a problem just let things in
20:45:02 <devananda> clarkb: fwiw, i've hit the same thing in ironic, and we worked around it in the same way
20:45:02 <mordred> we spend SO MUCH TIME dealing with pip and pypi releated challenges
20:45:08 <sdague> where n is the number of things in that list
20:45:10 <clarkb> if they meet the technical criteria that are established
20:45:23 <devananda> clarkb: adding importutils.tryimport and the like, for modules that are not in global requirements
20:45:28 <clarkb> py3k support, not duplicated functionality, licensing, etc
20:45:30 <devananda> it's hard on packagers and deployers
20:45:41 <clarkb> devananda: why? projects determine actual dependencies
20:45:43 <devananda> as they have to install additional things, not listed in the requjirements.txt file
20:45:44 <jeblair> clarkb: i agree.  i think if we have a big tent, then we let more things in here, but it's still useful for projects to try to converge on one set
20:45:57 <fungi> i would say the biggest challenge is finding enough people to do meaningful reviews of proposed additions/updates to avoid it turning into a free-for-all mess
20:46:02 <mordred> yah
20:46:02 <devananda> clarkb: I can't add something to ironic/requirements.txt if it's not in global requirements
20:46:05 <dhellmann> fungi: ++
20:46:07 <mordred> ultimately, we can set all the policy we want
20:46:28 <dhellmann> devananda: you can if you configure your d-g job to allow soft requirements
20:46:32 <clarkb> devananda: yes... I am saying add things if they meet the criteria
20:46:48 <clarkb> I don't like that the criteria goes beyond the technical list for choosing
20:47:11 <devananda> dhellmann: these are things which aren't needed in d-g
20:47:21 <devananda> dhellmann: eg, hardware drivers that we dont (and cant) test upstream
20:47:44 <devananda> but a distro may well want to make them available as packages, not just pip installs
20:47:44 <jeblair> devananda: then it's not really a requirement, is it?
20:47:51 <dhellmann> devananda: there are ways to get those into your test env, but yeah, what jeblair said
20:48:20 <devananda> jeblair: it is if you own that hardware
20:48:26 <sdague> jeblair: except if the goal is for the software to coexist, driver dependencies do matter
20:48:34 <sdague> which has been a giant punt at this point
20:48:40 <sdague> and every project does it differently
20:48:55 <jeblair> i'm sorry, i thought we were literally talking about the pip _requirements_ for projects
20:48:59 <sdague> some put them in requirements, some in test-requirements, some in no where
20:49:02 <dhellmann> are you suggesting we should include those requirements in this list, too?
20:49:37 <devananda> I didn't mean to derail from boris-42 's topic -- but I think it's closely related
20:49:52 <dhellmann> yeah, I'm just trying to understand all of the issues being raised
20:50:00 <mordred> I agree actually - I think g-r is going through a midle identity crisis
20:50:07 <devananda> for instance, the inclusion of python-ironicclient in nova's requirements.txt
20:50:09 <mordred> mild
20:50:15 <mordred> not midle - that's not a world
20:50:18 <mordred> or a word
20:50:19 <sdague> :)
20:50:20 <devananda> it's a requirement ONLY if you want to use that driver
20:50:20 * mordred stops typing
20:50:28 <jeblair> devananda: yeah, not saying it's not important, but i don't think it is solved well in python in general, and there's not much we can do about that here
20:50:39 <devananda> but then, today, you have to go install python0ironicclient by hand
20:50:49 <devananda> since it doesn't get caught by pip install -r requirements
20:51:08 <devananda> and yah, we work around that in d-g
20:51:21 <devananda> (er, in devstack somewhere)
20:51:25 * devananda waves hands
20:51:33 * mordred waves back
20:51:39 <ttx> So what's the next step for us in solving that mild identity crisis ?
20:51:40 <sdague> yeh, there is actually a bunch of work arounds in devstack for the driver issue
20:52:02 <fungi> for the thread boris-42 started on the ml though, it distills to "rally wants to test lots of things, so the clients it needs to interact with anything it tests should become an openstack requirement" which seems like a slippery slope
20:52:06 <clarkb> thats orthogonal. The issue at hand is whether or not we should relax the criteria for proper pip requirements in global requiirements repo
20:52:25 <clarkb> was responding to the ironicclient discussion not fungi
20:52:47 <clarkb> and I think it is reasonable to add requirements to g-r if they are used by openstack projects and otherwise meet the criteria
20:52:51 <dhellmann> devananda: https://www.python.org/dev/peps/pep-0426/#required-extension-handling (when implemented) would help with that
20:52:57 <devananda> fungi: the solution to that seems to be for rally to just install those clients in its test env?
20:53:10 <mordred> dhellmann: yah - that's gonna be a ways off though
20:53:12 <fungi> devananda: that was one proposed solution, yes
20:53:20 <dhellmann> mordred: yeah
20:53:37 <ttx> OK, this feels like a discussion we should develop on the ML -- anyone volunteering to kick it off ? Or should we just build on top of boris thread ?
20:53:46 <jeblair> yeah, i think boris-42's topic is solved by the soft requirements feature.  i don't think that's actionable by us.  however, i think the question of what do do with g-r in a big tent is interesting, and i think we should loosen the criteria as clarkb suggests
20:53:48 <sdague> ttx: I think the thread is there
20:53:53 * mordred is happy for g-r to be more inclusive from a "if you're going to use library X if needs to be version Y" filter from a policy perspective - but would realy like to dig in to the technical problem that g-r is solving and whether it's even the right way to do that
20:54:11 <mordred> especially in a big-tent world
20:54:24 <zaneb> jeblair: +1
20:54:43 <dhellmann> mordred: yeah, I'd be interested to see if the requirements compile thing in http://nvie.com/posts/better-package-management/ helps
20:55:01 <clarkb> except we shouldn't be testing with compiked packages
20:55:03 <ttx> OK, we need to move on
20:55:08 <mordred> dhellmann: ++
20:55:16 <dhellmann> clarkb: it compiles the requirements list itself, not the packages
20:55:29 <dhellmann> "compile" is used very loosely there -- read the post
20:55:30 <ttx> jeblair/clarkb: could one of you follow up on the thread suggesting loosening ?
20:55:45 <ttx> want to make sure we don't let this one drop back below radar
20:56:03 <clarkb> ya I can respond
20:56:03 * fungi already followed up on the thread, which i think is part of what prompted it to get added to the agenda for this meeting :/
20:56:08 <ttx> clarkb: thx
20:56:21 <ttx> Let's quickly cover/skip the rest of the agenda
20:56:26 <ttx> #topic Other governance changes
20:56:31 <ttx> * Correct formatting on some extra ATCs entries (https://review.openstack.org/147672)
20:56:36 <ttx> This is mostly cosmetic, so I'll approve it after meeting unless someone complains
20:56:54 <ttx> * Update David Chadwick ATC expiration (https://review.openstack.org/147673)
20:56:59 <ttx> This one has +1 from PTL, so I think we can approve it at the end of this meeting, unless someone complains
20:57:22 <ttx> #topic Open discussion
20:57:31 <ttx> vishy:  I fear we don't have a lot of time left
20:57:38 <ttx> maybe yo ucan introduce the topic again
20:57:41 <vishy> that’s ok
20:57:44 <mikal> Use your minute wisely
20:57:45 <ttx> * How to drive more resources to critical oslo libs (vishy)
20:57:58 <vishy> I’m concerned that some key oslo libraries aren’t getting the attention
20:58:01 <vishy> they need
20:58:06 <haypo> so just accept my change to add aioeventlet dependency :-D https://review.openstack.org/#/c/138750/
20:58:08 <vishy> despite dhellmann’s excellent efforts
20:58:12 <devananda> dhellmann: are you doing much on the aio work? it looks similar to what we're doing in Ironic, but probably better thought out
20:58:24 <devananda> haypo: ohhai :)
20:58:29 <dhellmann> devananda: I'm not involved in that directly right now. haypo is leading that up.
20:58:29 <haypo> dhellmann told me that a cross-project spec should we written for asyncio, is that right?
20:58:32 <vishy> oslo.db seems ok due to mike bayer putting a lot of work into it
20:58:47 <ttx> #action ttx to move trollius discussion to next week meeting agenda
20:58:49 <vishy> but oslo.messaging in particular seems lite
20:58:51 <dhellmann> vishy: messaging could use some love -- we have a lot of part-timers working on it
20:59:02 <dhellmann> as far as I know, I am the only person working on Oslo full time
20:59:18 <devananda> dhellmann: is anyone working on oslo'ifying nova objects?
20:59:21 <vishy> its a bit scary since it is a key piece of all openstack
20:59:25 <russellb> i think mike bayer feels like he has a hard time getting his stuff in, needing reviewers though
20:59:32 <dhellmann> bnemec, dims__, jd__, flaper87, and the other cores do great work, but have less time
20:59:38 <dhellmann> vishy: ++
20:59:42 <vishy> there is a bug currently that makes rabbit reconnect not work properly
20:59:44 <markmcclain> vishy: ++
20:59:51 <ttx> haypo: in the mean time we can have more discussion on the review
20:59:55 <vishy> it was totally broken for a very long time
21:00:01 <dhellmann> we have also, because of the graduation push, been focusing on that work rather than feature work for most of the libs for the kilo and juno
21:00:01 <ttx> haypo: sorry it couldn't fit in today
21:00:05 * dims_ peeks
21:00:23 <dhellmann> so, yeah, we could use more help :-)
21:00:27 <vishy> so perhaps there is some way we could encourage corporate entitites to help a bit more
21:00:28 <haypo> ttx: well, i don't know what i should add to the review. you may put questions there if you want
21:00:43 * devananda wishes he had more time to review oslo.db
21:00:46 <vishy> i don’t have any solutions per se
21:00:48 <fungi> oslo definitely seems like a place we risk tragedy of the commons
21:01:07 <vishy> so if anyone has ideas :)
21:01:16 <ttx> vishy: an "oslo is important and needs yor help" blogpost would help
21:01:29 <russellb> i'd retweet that :-p
21:01:36 <vishy> sounds like an interesting idea
21:01:40 <dims_> hehe
21:01:43 <dims_> +1
21:01:46 <vishy> maybe I will try to put something together
21:01:48 <ttx> It's certainly time for us to refmect back on what a critical piece oslo has become
21:02:13 <dhellmann> messaging isn't going to benefit from drive-by reviewers, though -- I would rather have 1-2 people really interested than 10 with a few minutes here and there
21:02:14 <ttx> and make it shiny and encourage people to dedicate resources to it
21:02:20 <ttx> ok, we are over teim
21:02:23 <ttx> time even
21:02:30 <ttx> Anything else, anyone ?
21:02:37 <ttx> last minute words ?
21:02:44 <dhellmann> vishy: thanks for raising the issue :-)
21:02:49 <annegentle> flibbertyjibbitz
21:02:55 <jeblair> ttx: thanks!
21:03:02 <ttx> annegentle: is that your password ?
21:03:04 <ttx> #endmeeting