20:00:54 <ttx> #startmeeting tc
20:00:56 <openstack> Meeting started Tue Mar 15 20:00:54 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:57 <amrith> ./
20:00:57 <russellb> hi
20:00:59 * rockyg tries to stay quiet in the back of the room
20:01:00 <openstack> The meeting name has been set to 'tc'
20:01:09 <ttx> Hellllooo everyone!
20:01:14 <ttx> Our agenda for today:
20:01:15 <flaper87> yoooooooooo
20:01:20 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:33 <jaypipes> I is here.
20:01:37 <ttx> #topic Extra ATCs
20:01:42 <ttx> We have a couple extra ATCs requests to rubberstamp.
20:01:50 <ttx> NB: the governance repo was tagged for elections last week though, so those won't vote in upcoming elections
20:02:05 <ttx> unless we start doing very funny things
20:02:09 <ttx> * Adding Horizon extra-atc (https://review.openstack.org/290188)
20:02:20 <fungi> i'm not in favor of doing funny things with the election
20:02:33 <ttx> that one has enough to pass, will approve now
20:02:39 <ttx> * Add dencaval to extra-atcs for Manila (https://review.openstack.org/289408)
20:02:46 <annegentle> o/
20:02:47 <fungi> already doing final testing on our roll generation tooling based on the existing tag
20:02:50 <ttx> this one is missing one
20:03:01 <annegentle> was there a deadline missed for dencaval to need extra atc?
20:03:12 <annegentle> I don't see a need for it but maybe someone can explain
20:03:19 <ttx> annegentle: start of PTL nomination period
20:03:29 <annegentle> ttx: ah for elections then?
20:03:29 <bswartz> annegentle: I thought he deserved voting rights in Manila, as well as docs
20:03:29 <russellb> annegentle: just commented
20:03:33 <ttx> annegentle: that is when we tag the governance repo and start generating rolls
20:03:37 <annegentle> I'm on spring break but popped in for this
20:03:41 <annegentle> thanks russellb
20:03:46 <anteaya> annegentle: dencaval has atc for docs, bswartz just wanted him in manilla too
20:03:47 <annegentle> needed to understand
20:03:50 <russellb> annegentle: it's voting rights in manila as well
20:03:51 <annegentle> got it
20:03:55 <dhellmann> bswartz : I think ttx and fungi just said it would be too late for this election anyway?
20:04:08 <ttx> that will be valid for the next
20:04:08 <bswartz> yes that's my fault
20:04:08 <russellb> still reasonable for next time around
20:04:15 <david-lyle> voting rights last two cycles
20:04:16 <dhellmann> ok, just making sure that's clear
20:04:18 <mestery> russellb: ++
20:04:21 <bswartz> I've already conveyed my apologies
20:04:34 <ttx> alright both approved
20:04:39 <david-lyle> thanks
20:04:42 <ttx> #topic Update Kuryr mission statement
20:04:52 <fungi> it will come into effect for ocata elections and summit passes for barcelona
20:04:57 <mordred> o/
20:04:58 <ttx> #link https://review.openstack.org/289993
20:05:05 <ttx> So this is about extending the bridging mission of Kuryr to also include storage features
20:05:21 <ttx> It's a significant change but I think it makes sense
20:05:29 <russellb> I still don't get it
20:05:55 <russellb> these are really high level use cases, but it's not clear what actual code is to be written
20:06:02 <russellb> and where that code plugs into the overall system
20:06:08 <ttx> russellb: I'm not 100% sure what they will end up needing doing, yes
20:06:22 <ttx> since for example Kubernetes has a cinder plugin
20:06:30 <russellb> i'd expect a bit more confidence in specific deliverables than this
20:06:48 <mestery> The bit about persistent storage for containers sounds interesting, though not conrete
20:06:52 <ttx> but they seem convinced there are interesting things to do, and I'm fine with them exploring
20:06:54 <mestery> *concrete
20:07:15 <ttx> now if only Gerrit would ah.
20:07:17 <mestery> ttx: +1, to me I'm ok with it as well
20:07:52 <russellb> ok, well recorded my -1 fwiw.  i'd rather just not rubber stamp these things
20:08:19 <flaper87> I think it's fine to wait a bit longer and have a more specific mission statement
20:08:20 <ttx> russellb: I'm fine delying until we can get better answers from Gal
20:08:24 <mestery> russellb: Agree
20:08:34 <ttx> I raised the fuzziness first after all
20:08:38 <russellb> ttx: right
20:08:49 <dhellmann> I'd be ok with that, too.
20:08:54 <mestery> russellb: I meant, I agree with not rubber stamping
20:08:54 <lifeless> ttx: o/
20:08:57 <jeblair> yeah, the answers so far are almost as broad as the proposed mission statement
20:09:04 <mestery> I'd be fine waiting a bit more, but I'm also ok trusting the team to move forward here and explore a bit
20:09:09 <jeblair> and i'm struggling with making it concrete --
20:09:14 <russellb> don't need to update mission statement to explore
20:09:16 <ttx> russellb: can you take the action to reach out and get a cleaner explanation, or even (gasp) a ML thread about it ?
20:09:26 <russellb> i've tried in gerrit
20:09:34 <mestery> russellb: Fair point
20:09:35 <ttx> russellb: I think it warrants a ML thread to be fair
20:09:38 <russellb> ok
20:09:39 <russellb> i can do that
20:09:52 <ttx> if only so that the rest of the community sees it better
20:09:59 <jaypipes> "Kuryr is the glue between the container world and OpenStack APIs"?
20:10:28 <ttx> jaypipes: basically, no need to create glue if storage does not need glue
20:10:43 <jaypipes> ttx: docker has a Cinder plugin?
20:10:44 <russellb> the network case was clear, there are very clear plugin interfaces
20:10:54 <russellb> i just want to know the equivalent for storage that they are targeting here
20:11:17 <russellb> because without that, it's not clear to me that openstack should have a project for it
20:11:21 <ttx> jaypipes: no but (1) k8s has, and (2) that might point to the possibility of adding it in Docker rather than OpenStack
20:11:23 <russellb> vs working upstream in container thingy projects
20:11:33 <ttx> hence more precision needed
20:11:39 <jaypipes> ttx: fair enough points.
20:12:00 <ttx> I'm not saying no (I actually still am a YEs on the proposal) but I agree with Russell this could use more clarity on the goals
20:12:12 <russellb> yep, and i'm not upset if i'm overridden really :)
20:12:39 <annegentle> I'm happy with the use case getting more discussion so we all understand more
20:12:41 <russellb> but "does this actually make sense" is a good question to ask :)
20:12:42 <ttx> Also it sounds like extending a team mission should at the very minimum cause a ML thread, if only to attract more contributors
20:12:47 <annegentle> russellb: yah
20:12:47 <flaper87> I'm ok with waiting. More clarification is good and if the mission statement change is required then we better get it right otherwise it'll be upated again next cycle
20:13:36 <ttx> #info waiting one more week for extra precision
20:13:56 <ttx> #action russellb to follow up in a ML thread
20:14:20 <ttx> #topic Add a resolution for PTL Leave of Absence
20:14:25 <ttx> #link https://review.openstack.org/290141
20:14:33 <ttx> anteaya posted a resolution to clarify TC communication expectations on PTLs leaves of absence
20:14:37 * annegentle admits she hasn't read it yet
20:14:47 <ttx> The preferred option is of course public communication, but there are some cases where the PTL would rather not go public with the details, so there are backup solutions as well
20:14:57 <ttx> There was some opposition to the resolution, mostly about the "communicate to the TC" part if I read the comments correctly
20:15:10 <ttx> I think that's partly a misunderstanding on what the resolution is trying to achieve -- this is not about the PTLs communication duties toward their teams
20:15:15 <russellb> i'd rather assume PTLs use good judgement and work this out within their teams
20:15:17 <ttx> It's about clarifying the official projects PTLs communication duties toward the TC
20:15:34 <dhellmann> yeah, the issue is all of the interface points outside of a team that also need to know about these changes
20:15:34 <ttx> I think we can further document the PTLs communication duties toward their teams, but I see that as belonging in the Project Team Guide rather than governance
20:15:36 <russellb> feels like massive overkill in policy
20:15:44 <dtroyer> can we clarify the requirements/desires without specifying implementation?
20:15:45 <mestery> russellb: ++
20:16:00 <dhellmann> russellb : "Please tell folks if you're going to be gone for a long time and you lead a project" is overkill?
20:16:12 <russellb> i don't think we need a resolution for it
20:16:15 <lifeless> Ubuntu has a code of leadership which speaks to this
20:16:25 <dhellmann> russellb : so how do we address it?
20:16:35 <lifeless> I think the current proposal is overly proscriptive
20:16:39 <sdague> we kind of already had the "step down gracefully" clause buried somewhere
20:16:47 <dtroyer> I see two things to think about: 1) elected leaders have a responsibility to those who elected them
20:16:54 <ttx> We could just document it on the Project Team Guide. But I don't think a resolution is overkill either.
20:17:02 <lifeless> I'd support something that just highlights the required outcome
20:17:09 <annegentle> My initial sense is that what you really want to have a policy for is PTL disappearence/non-communication. Also consider the case where a PTL is pregnant (hey, it can happen), would she need to not run in the time period?
20:17:11 <lifeless> which is that folk don't go awol
20:17:16 <anteaya> sdague: that is the smooth tranistions expectation, but I don't know if this was a transisiton or not, hence the desire for more facts
20:17:18 <dtroyer> 2) the TC is the focal point for working across the other tehnical leaders in projects
20:17:19 <annegentle> lifeless: that's my read of it too
20:17:37 <mestery> I like jaypipes's comments: Lets trust PTLs and project teams to handle this on their own, communicating with the TC. If the TC needs to step in to help, we can do that.
20:17:39 <sdague> so I think I'm on the side that we don't need another policy for this
20:17:41 <ttx> dtroyer: yes that's it
20:17:42 <annegentle> vacations, known predictable medical leave, those are having a life
20:18:01 <anteaya> annegentle: this doesn't cover vactation
20:18:06 <anteaya> this is unexpected events
20:18:11 <anteaya> non planned
20:18:12 <sdague> community norms weren't followed, step down gracefully should cover this.
20:18:12 <dhellmann> mestery : so this came about because of the situation with trove last week, in which a lot of people were surprised and up in arms because the ptl was out for a couple of weeks and only a few folks outside of the team knew.
20:18:23 <anteaya> sdague: should but didn't
20:18:28 <russellb> was there actually a problem with trove?
20:18:33 <ttx> sdague: is it documented somewhere (the "step down gracefully" ?)
20:18:35 <russellb> we clearly had someone available to talk to and work with
20:18:36 <mestery> dhellmann: OK, so what happened that was super bad during that time period?
20:18:39 <russellb> it wasn't hard to figure out
20:18:39 <lifeless> sure, but its too low level; we can't legislate every eventuality. Was this prompted by some PTL going awol ?
20:18:44 <mestery> Did the release for trove go bad or not happen (that would be bad)?
20:18:50 <dhellmann> russellb : no. he was out for a few weeks, he came back, everything was handled except for whatever happened in the meeting last week.
20:18:58 <flaper87> As I mentioned in the spec, I'm also not in favor of having a policy for this. I'd rather rely on the common sense of PTLs and, most importantly, the community's
20:18:59 <ttx> lifeless: yes, trove PTl was out but most didn't know
20:19:01 <mestery> OK, so sounds like common sense prevailed?
20:19:16 <sdague> I swore it was in our community standards somewhere, grepping
20:19:31 <ttx> sdague: if it's already documented somewhere I'm fine not adding a layer
20:19:36 <jeblair> someone from the project came to the tc meeting and told us that though.  i'm not upset.
20:19:39 <annegentle> sdague: grep man grep
20:19:43 <russellb> jeblair: ++
20:19:43 <dhellmann> if we look past the prescriptive language in this resolution, I'm having a hard time understanding why we wouldn't want to write down that we expect folks to announce this sort of thing
20:20:09 <anteaya> especially if they happen to be stressed
20:20:12 <dhellmann> jeblair : yeah, it was the qa folks I think
20:20:13 <thingee> sdague: https://wiki.openstack.org/wiki/PTL_Guide#Availability ?
20:20:17 <dhellmann> (that were upset)
20:20:18 <flaper87> and if we really want to add the resolution, I'd avoid mentioning all the steps and perhaps simplify it with: "let us know, please"
20:20:18 <anteaya> and are trying to figure out the right thing to do
20:20:26 <russellb> more that it feels so heavyweight ... if we have to write this down, do we need formal policies for everything that seems like reasonable common sense
20:20:41 <dhellmann> flaper87 : I agree with making this proposal simpler
20:20:48 <mestery> flaper87: ++
20:20:59 <mestery> Resolution: IF as PTL you're going somewhere, let your project team and the TC know.
20:21:04 <mestery> Seems pretty simple
20:21:06 <ttx> how about we turn it into something we add to the project team guide ?
20:21:11 <markmcclain> flaper87: that's what I suggested in the comments
20:21:12 <dtroyer> ttx: +++
20:21:13 <russellb> ttx: sounds reasonable
20:21:14 <sdague> thingee: yeh, I think thwas was it
20:21:15 <dhellmann> ttx: that works
20:21:19 <anteaya> you don't have to go anywhere to not be able to fulfill your obligations
20:21:21 <annegentle> ttx: that would work, and make sure you have a proxy assigned
20:21:24 <thingee> ttx: https://wiki.openstack.org/wiki/PTL_Guide#Availability
20:21:27 <anteaya> you can still be at home/office
20:21:30 <dhellmann> anteaya : figure of speach
20:21:32 <flaper87> markmcclain: yeah, I did as well but...
20:21:32 <thingee> just move that from the wiki
20:21:35 <ttx> thingee: that's not official doc anymore
20:21:38 <ttx> thingee: right
20:21:42 <mestery> I'm not in favor of prescriptively documenting common sense in this case
20:21:42 <jeblair> ttx: if the bit thingee posted isn't in the guide, i think that's a great thing to include
20:22:06 <ttx> someone needs to care enough to push that. That is why I was fine with the resolution model, whatever the author prefers basically
20:22:16 <flaper87> To me, the most important part is for the team to know the PTL is not going to be around. IF they manage to nominate an interim PTL, that's more than awesome. IMHO
20:22:23 <flaper87> An email to the ML is great
20:22:27 <ttx> do we have a volunteer to push that in the PTG instead ?
20:22:29 <thingee> ttx: I can do it
20:22:31 <mestery> flaper87: Agreed
20:22:34 <russellb> thingee: thanks!
20:22:37 <dhellmann> thanks, thingee
20:22:54 <sdague> thingee: awesome, thanks
20:23:01 <sdague> and good find on it :)
20:23:04 <ttx> Personally I think the PTG is more discoverable and less intimidating than a resolution, so I'm fine with it landing there
20:23:10 <jeblair> thingee: there's some similar language in doc/source/open-community.rst ; so maybe an enhancement to that
20:23:37 <russellb> ttx: ++
20:23:44 <mestery> ttx: ++
20:24:14 <annegentle> agreed let's not make it less appealing/possible to be PTL :)
20:24:15 <lifeless> I think we have consensus, lets move on?
20:24:27 <ttx> yes
20:24:34 <jeblair> thingee: http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections
20:24:40 <ttx> #agreed Push the thing to the PTG instead
20:24:58 <thingee> jeblair: thanks
20:24:59 <ttx> #action thingee to propose a PTG change to cover expectations on PTLs
20:25:16 <annegentle> thanks anteaya for bringing it up; obviously needed some thoughtful discussion
20:25:26 <jeblair> anteaya: ++
20:25:30 <lifeless> ++
20:25:33 <russellb> ++
20:25:37 <markmcclain> ++
20:25:49 <anteaya> well brought you all together
20:25:53 <anteaya> who else can do that?
20:26:03 <ttx> Alrighty
20:26:12 <ttx> #topic Open discussion
20:26:13 * jeblair has an answer but keeps it to himself
20:26:19 <ttx> * Status update on the testing interface conformance issues found in Trove
20:26:23 <amrith> To be respectful of everyone's time, and so you don't have to all watch me type this, I've put these comments on gist.
20:26:23 <amrith> https://gist.github.com/amrith/343415cda4a937f78eac#file-trove-stable-liberty-txt
20:26:42 <ttx> tl;dr is most issues were fixed ?
20:26:49 * ttx reads
20:26:51 <amrith> yes, the summary is this
20:26:59 <amrith> In summary, let me say that the stable/liberty gate is now working
20:26:59 <amrith> again and is reliable. More needs to be done, and there is a plan to
20:26:59 <amrith> address it in stable/liberty, stable/mitaka and moving forward.
20:27:15 <amrith> I would also like to thank Matt for escalating this issue.
20:27:27 <amrith> and I'll be working with him to take care of some final 'cats and dogs' ...
20:28:02 <russellb> the cats and dogs that are raining down?
20:28:16 <ttx> alright, it seems the issue is now closed and doesn't need TC follow-up
20:28:18 <flaper87> amrith: thanks for working on that
20:28:30 <russellb> thanks amrith !
20:28:31 <amrith> russellb, if you are near where I am, yes it is raining hard. they call it New England for a reason ;)
20:28:32 <ttx> yes, thx amrith for jumping on the issue and fixing it
20:28:47 <amrith> thanks to all for the help getting the issues resolved.
20:28:47 <lifeless> it is raining cats and dogs here, for sure
20:28:49 <russellb> i'm in California today, very dry
20:29:00 <ttx> do we have both mordred and lifeless ?
20:29:23 <tristanC> Quick update from elections: 51Hour left, 25 projects are missing candidates (which is about 47%)
20:29:26 <flaper87> Just a heads up from the comm team: A blog post is being written. It started after our last meeting but there was not enough time. Hopefully will go out in the next couple of days
20:29:35 <annegentle> thanks flaper87
20:29:39 <lifeless> ttx: reporting for duty
20:29:49 <ttx> mordred: around ? if yes I'd like to get deeper in the discussion we started two weeks ago
20:29:50 <mordred> ttx: I am here!
20:29:57 <ttx> * Are GPL test-only Python library dependencies an issue or not ? (lifeless, mordred)
20:30:00 <ttx> About lifeless comments on https://review.openstack.org/#/c/279999/
20:30:03 <lifeless> mordred: was just about to ring you :)
20:30:04 <mordred> I feel like lifeless and I got somewhere
20:30:08 <ttx> The question is... should GPL test-time library dependencies (like scapy or Mysql-Python) be considered ok or not
20:30:09 <annegentle> thanks tristanC
20:30:11 <mordred> when we chatted a couple of weeks ago
20:30:16 <ttx> lifeless seems to think they aren't ok, mordred seemed to think they are ok
20:30:22 <ttx> fight!
20:30:24 <mordred> I believe we've gotten to a middle ground
20:30:27 <flaper87> ttx: lol
20:30:28 <ttx> dammit
20:30:30 <lifeless> ttx: I think we agreed that we can't say yes or no to that question
20:30:30 <jeblair> boring
20:30:34 <flaper87> buuuu
20:30:34 <mordred> yah.
20:30:36 * flaper87 yawns
20:30:38 <dims> boo
20:30:38 <thingee> from cross-project land, I surfaced up some stale specs http://lists.openstack.org/pipermail/openstack-dev/2016-March/089115.html
20:30:40 <lifeless> ttx: sometimes they will. Sometimes they won't.
20:30:40 <mordred> that it depends on the dependency
20:30:46 <mordred> and we shoudl use human judgement
20:30:47 <ttx> what sort of fight is this
20:30:54 <annegentle> ha
20:30:55 <mordred> ttx: we fought in #openstack-dev
20:30:58 <mordred> you missed it
20:30:58 <lifeless> ttx: so -> the blanket rule is that we have to assess each one.
20:31:06 <thingee> I'd be interested in either someone interested in reviving these or the TC agreeing on some of these old specs being abandoned
20:31:23 <ttx> lifeless: is there something we can add to the licensing requirements to make the rule clearer ?
20:31:30 <ttx> or what we'd use to assess the rule ?
20:31:44 <lifeless> ttx: so its messy
20:31:47 <ttx> because I'm not sure "asking mordred and lifeless about it" is scalable and durable
20:31:48 <flaper87> thingee: gotta admit, it took me a bit longer to parse that last sentence
20:32:08 <markmcclain> ttx: ++
20:32:09 <sdague> ttx: well, it's infrequent enough, I'm actually comfortable with ask mordred and lifeless
20:32:31 <sdague> I think it's more scalable than trying to define a process for it with everyone honestly :)
20:32:33 <ttx> I'm ok with asking lifeless and mordred as long as they agree with my view of it
20:32:33 <lifeless> ttx: so, this specific proposal is invalid, because its making a blanket it's-ok rule.
20:32:40 <mordred> yup
20:32:52 <dims> sdague : ttx : my suggestion was that what's needed should be made available via infra (images?) and not added to *requirements.txt
20:32:52 <mordred> but a blanket it's-not-ok is also not the right thing
20:32:59 <lifeless> ttx: we can say something like 'invoking tools that are under any OSI approved license' is ok
20:33:04 <ttx> lifeless: so since it merged we should post a clarification
20:33:21 <lifeless> ttx: because I think both mordred and I would agree that that is always ok, as far as it goes.
20:33:35 <mordred> yup
20:33:35 * rockyg thinks maybe a set of questions to answer before submitting a patch to include in test reqs?
20:33:47 <lifeless> its where things get into interface based derivation that it gets messy
20:33:50 <ttx> right, calling tools is ok, everything else is more on a case-by-case basis of defining extension of work
20:33:54 <mordred> yah
20:34:00 <ttx> that would be my take as well
20:34:05 <lifeless> the thing that provoked this was use of a python library
20:34:12 <ttx> We might want to kick Python-MySQL out then
20:34:18 <ttx> and ask ourselves the question later ?
20:34:25 <mordred> it has a specific carve-out
20:34:28 <sdague> python-mysql has the foss exception, right?
20:34:31 <lifeless> which is why it's ok ...
20:34:33 <dims> right
20:34:34 <mordred> libmysqlclient has the FOSS excpetion
20:34:38 <lifeless> and why blanket rules are hard here
20:34:39 <ttx> oh right
20:34:51 <mordred> yah. turns out humans are good at assessing things and applying judgement
20:34:59 <ttx> we should probably add that to the # GPL comment
20:35:05 <mordred> in this case, we should call out that doing so is a good idea
20:35:06 <ttx> mordred: nonsense!
20:35:06 <dims> ttx : yep +1
20:35:49 <lifeless> I'll add a tweak to requirements and propose a licensing.rst tweak
20:35:54 <jeblair> i feel like there's a subtext that hasn't quite been said here...
20:35:57 <ttx> lifeless, mordred: is one of you interested in proposing a new wording that outlines the OK scenario and the "we need to think about it" scenario ?
20:36:08 <lifeless> to make it clearer that the blanket thing there is 'running things' not 'using libraries'
20:36:08 <ttx> lifeless: ++
20:36:20 <ttx> lifeless: ++
20:36:31 <lifeless> mordred: (and no, I know using is the wrong word, but in the absence of better ones :))
20:36:33 <ttx> #action lifeless to propose a licensing.rst tweak
20:36:36 <russellb> we could also identify a small group of people as the people that should be tagged on reviews where the licensing questions aren't clear
20:36:40 <jeblair> which is that 'using libraries' is maybe not ok
20:36:41 <mordred> lifeless: yah yah
20:36:43 <sdague> russellb: yeh
20:36:52 <sdague> which is the mordred / lifeless solution
20:36:53 <russellb> because it can't be solved completely with policy
20:36:57 <jeblair> which i'm not convinced is the case
20:36:58 <sdague> russellb: ++
20:37:27 <jeblair> i'm wondering, in the example of scapy -- do folks feel it's inappropriate?  if so, why?
20:37:31 <mestery> russellb: ++
20:37:32 <dims> we still have no way to prevent test libs from leaking into runtime
20:37:36 <mordred> jeblair: I think lifeless point is that there might be cases where using a library would in fact be a case that a derived work would be the result
20:37:46 <lifeless> dims: I don't see a difference between runtime and testtime
20:37:57 <lifeless> dims: mechanically they are identical
20:38:01 <jeblair> mordred: i agree it could happen.  but i see a difference between runtime and testtime :)
20:38:10 <mordred> jeblair: and that looking at what the library is and how it's being used is the thing that's eventually going to be the deciding factor of that
20:38:14 <mordred> jeblair: I do too
20:38:16 <lifeless> dims: if the GPL has any relevance to Python code, the situations are identical
20:38:18 <dhellmann> yeah, I'm not sure why we don't make a test/production distinction
20:38:22 <jeblair> (who's distributing the binary that results when i run a test in the gate?)
20:38:27 <mordred> jeblair: but I think it's worth a specific discussion of each case
20:38:40 <mordred> jeblair: becuase having the abstract discussion on it has so far been unsuccessful
20:38:41 <dims> jeblair : right
20:38:43 <lifeless> dhellmann: from a distribution perspective (remember, GPL is a distribution license...)
20:38:44 <ttx> and it's rare enough to make the cost of discussing it low
20:38:47 <jeblair> mordred: ok.  i can be down with that.
20:38:50 <gus> (my personal relevant example here is pylint:  I wrote some openstack-specific pylint checks previously, but have nowhere to store them.  Clearly derived works from pylint (GPL), but also code that is easy to mentally separate from actual regular openstack deliverables)
20:39:06 <dims> gus : ++
20:39:09 <lifeless> in the specific case of scapy, I want us to check with upstream
20:39:26 <jeblair> lifeless: i think that's a fantastic idea.
20:39:27 <lifeless> GPLv2 only is identified as ASLv2 incompatible by the FSF
20:39:55 <mordred> if the author of scapy is fine with our use of it, then I tihnk we have no issue
20:39:57 <jeblair> yeah, but "incompatible" doesn't begin to describe the nuance :)
20:40:00 <mordred> yah
20:40:04 <lifeless> If their intent is to be incompatible, we shouldn't use it - we don't want to be the test case for 'The GPL is meaningless for Python programs'
20:40:21 <jeblair> lifeless: agreed
20:40:22 <mordred> if their intent is to be incomptible I want to have a discussion about it
20:40:25 <lifeless> I mean, maybe we do - but it would be a fairly massive distraction
20:40:27 <mordred> because I'm more of an ass
20:40:37 <mordred> but I do think checking first is the right move
20:40:38 <ttx> <tristanC> Quick update from elections: 51Hour left, 25 projects are missing candidates (which is about 47%)
20:40:45 <mordred> and depending on the feedback, it might be a very quick discussion
20:40:45 <lifeless> I'd *love* to have that discussion, kindof.
20:40:55 <ttx> #info Quick update from elections: 51Hour left, 25 projects are missing candidates (which is about 47%)
20:41:13 <ttx> so hopefully we'll receive nominations and not have to appoint dozens of PTls in our next meeting
20:41:47 <flaper87> ++
20:41:51 <lifeless> Omer has abandoned the scapy review
20:41:58 <lifeless> so its a bit moot
20:42:30 <tristanC> well, we're going to send the 'last hours' announcement to motivate ptl-less project
20:42:44 <ttx> btw some PTLs did not answer at all to our emails asking them for how much rooms they wanted at the design summit, if they don't have a PTL candidate either, I propose we fastrack their removal
20:42:53 <jeblair> lifeless: did we succeed in killing it with bureaucracy?
20:43:07 <ttx> death by review
20:43:15 <russellb> ttx: heh, which ones?  long list?
20:43:19 <jeblair> ttx: ++removal
20:43:24 <mestery> ttx: ++
20:43:25 <annegentle> ttx: as many as are not running PTLs?
20:43:27 <ttx> russellb: no, short.
20:43:32 <sdague> ttx: ++
20:43:33 <russellb> that's good to hear ...
20:43:50 <ttx> Thanks to thingee for being exceptionally persistent
20:43:56 <annegentle> nice thingee
20:44:18 <lifeless> jeblair: '
20:44:19 <lifeless> Following Doug Hellmann's and @lifeless' comments, I will try and find another solution.'
20:44:20 <annegentle> so our best guess is that most PTLs will stand again and just haven't sent in a patch?
20:44:21 <ttx> Slot allocatiojn to be published tomorrow
20:44:29 <lifeless> jeblair: so yes, I think.
20:44:44 <cdent> lifeless: can you link me to that review please?
20:44:45 <russellb> openstack governance garbage collection?  :)
20:44:49 <ttx> annegentle: a lot submissions just drop on the last day
20:44:54 <lifeless> https://review.openstack.org/#/c/277893/
20:44:55 <mestery> russellb: lol
20:45:01 <annegentle> ttx: yah
20:45:02 <ttx> russellb: that is my TC election platform
20:45:06 <russellb> nice
20:45:24 <russellb> no summit slots, no PTL, the reference count for this project has reached 0 and will now be removed
20:45:35 <cdent> thanks
20:45:41 <jeblair> lifeless: that's a shame.  i honestly feel there is a very good argument for using it.
20:45:42 <sdague> russellb: NullPointerException
20:45:47 <ttx> We got out of the way successfully, but we approved a lot of things by leaps of faith. I'd argue newton is cleanup time
20:46:12 * flaper87 likes that
20:46:16 <mestery> ttx: Sounds like an 80s movie: "OpenStack Newton: It's payback time."
20:46:18 <jeblair> lifeless: but i also agree it's not worth having if the question is moot.
20:46:19 <russellb> yes, we should protect "in OpenStack" as having some real meaning
20:46:20 <annegentle> ttx: yeah
20:46:21 <dhellmann> jeblair , lifeless : my -2 was procedural there for the freeze :-/
20:46:33 <ttx> we have 15 more minutes, any topic you'd like to discuss ?
20:46:40 <sdague> https://review.openstack.org/#/c/292918/
20:46:56 <sdague> we seemed to have not had a testing clause in the asserts can upgrade tag
20:47:07 <sdague> which I think is an oversight we should fix up
20:47:07 <lifeless> dhellmann: yes, I know
20:47:31 <ttx> sdague: how about the same commit removes the tag from affected projects ? That would make the consequence clearer
20:47:42 <russellb> sdague: ++
20:47:43 <dansmith> ttx: I can, if you like
20:47:50 <dhellmann> dansmith : yeah, please do
20:47:54 <dansmith> roger
20:48:02 <russellb> thanks dane_leblanc
20:48:04 <sdague> it's the 2 non ceilometer telemetry projects I think
20:48:04 <russellb> err, thanks dansmith
20:48:08 <ttx> heh
20:48:26 <sdague> but there might be something else complicated there about why they are getting tested because they are all very complicated in how they test
20:48:31 <lifeless> jeblair: I think its a great testing tool to use; in C land it would be unambiguous about how it could be used
20:48:52 <dansmith> I'll survey the project config, propose to remove the ones I think aren't right, and maybe we can get the PTLs to confirm
20:51:35 <russellb> *crickets*
20:51:36 <jeblair> lifeless: yep.  with us not distributing scapy itself, i think only section 2b would be at issue, right?  and then that would be asking whether dragonflow was derived from scapy.  with it only being used as a test-time requirement, i think that would be a stretch.
20:52:04 <dhellmann> maybe the dragonflow test suite would have to be gpled
20:52:29 <jeblair> lifeless: whether that then results in us laying a minefield for downstream packagers is an open question.  :)
20:52:37 <lifeless> jeblair: in C land, there would be a separate binary for tests, and one could simply not distribute that binary
20:52:51 <sdague> lifeless: you can simply not distribute our tests
20:53:16 <lifeless> sdague: as jeblair says - ?minefield
20:53:58 <lifeless> I'm sure everyone here gets that one of the key things the GPL works on is totally missing in Python: there is no derivation or inclusion of an interface at compile time
20:54:23 <lifeless> the oracle case that made interface copyright a thing re-introduces that though
20:55:06 <lifeless> sdague: so - practical consequence of 'simply not' - we'd need to teach pbr to exclude tests from wheels that we publish to pypi
20:55:18 <jroll> sdague: upgrades tag thing is interesting, I thought there was a testing clause there before (which is why ironic hasn't asserted that tag)
20:55:30 <sdague> jroll: I did too
20:55:34 <sdague> and I think there should be
20:56:11 <jroll> +1
20:56:30 <lifeless> anyhow, I still think the simplest thing is just to ask scapy - 'hey, if we used scapy in our test suite, would you consider that OK or not' ?
20:56:30 <sdague> just because we've found so many issues when enabling it in projects, and it helps expose upgrade issues to devs they might not have thought about
20:56:39 <amrith> a question ... when's the next TC meeting? 2 weeks?
20:56:49 <jeblair> lifeless, sdague: that's *if* dragonflow tests are considered derived works; there's an argument they may not be.
20:56:51 <lifeless> if upstream don't have an issue, meh, move on.
20:56:53 <jeblair> lifeless: but yes, that.  :)
20:57:15 <anteaya> amrith: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
20:57:31 <lifeless> jeblair: I actually need to make time to read the oracle-google decision in detail w.r.t. interface copyright
20:57:40 <lifeless> jeblair: I rather suspect it has significant bearing on that question
20:57:56 <amrith> good I asked, I thought it was 2 weeks ... thx anteaya
20:58:06 <anteaya> amrith: welcome
20:58:43 <dtroyer> lifeless: yes, also keep in mind that a single decision doesn't make it settled precedent yet, only in a single US Circuit…  still can't be ignored though
20:58:59 <jeblair> lifeless: that will be interesting.  also, totally looking forward to the gpl behaving differently in the 9th circuit :)
20:59:00 <lifeless> dtroyer: indeed
20:59:01 <jeblair> dtroyer: yeah
20:59:14 <lifeless> jeblair: its under appeal?
20:59:30 <jeblair> lifeless: i don't know
20:59:42 <lifeless> jeblair: oh - I don't get the 9th circuit ref then ?
20:59:51 * dtroyer still misses Groklaw
21:00:00 <lifeless> dtroyer: ++ :(
21:00:04 <egon> :-/
21:00:22 <dims> lifeless : https://www.ca9.uscourts.gov/
21:00:22 <ttx> oh well, time is up
21:00:25 <dtroyer> lifeless: that's where the current decision was made, other curcuits do not have to necessarily follow it
21:00:36 <russellb> thanks everyone!
21:00:38 <ttx> Thanks everyone!
21:00:44 <jeblair> lifeless: i thought it was a 9th circuit decision
21:00:44 <flaper87> o/
21:00:48 <ttx> #endmeeting