20:02:32 <ttx> #startmeeting tc
20:02:33 <openstack> Meeting started Tue Jan 19 20:02:32 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:36 <openstack> The meeting name has been set to 'tc'
20:02:39 <ttx> Hi everyone!
20:02:43 <flaper87> o/
20:02:46 <ttx> Our agenda for today:
20:02:48 * rockyg hides behind edleafe
20:02:55 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:08 <ttx> First we have two end-user-experience-oriented crossproject specs to give final approval to
20:03:14 <ttx> #topic Rubberstamp cross-project spec: Deprecate individual CLIs in favour of OSC
20:03:20 <ttx> #link https://review.openstack.org/#/c/243348/
20:03:33 <ttx> It looks like everyone on the review agrees it's a good idea.
20:03:40 <ttx> jd__ used the wrong review tool to post his -1: https://twitter.com/juldanjou/status/689035654014078976
20:03:58 <ttx> So unless someone elaborates on why this could possibly be a bad idea, I will approve it now.
20:04:12 <flaper87> I think it's a matter of taste
20:04:23 <flaper87> at least, tat's my interpretation of his complaint
20:04:44 <flaper87> There are certainly some drawbacks from an usability perspective, I think. But, overall, there's no major objection from me
20:04:53 <russellb> hi
20:05:12 <ttx> no last-minute objection ?
20:05:19 <annegentle> stamp it!
20:05:28 <sdague> it also doesn't get rid of the per project clients, it's just that we should lead with osc
20:05:32 * ttx looms over the new blue Workflow+1 button
20:05:32 <sdague> which I think is fine
20:05:39 <annegentle> shiny blue
20:05:40 <mestery> sdague: ++
20:05:50 <ttx> applied score with one click
20:05:52 <annegentle> yeah I think it's pragmatic and the way forward
20:05:59 <ttx> #topic Rubberstamp cross-project spec: Add clouds.yaml support specification
20:06:06 <ttx> #link https://review.openstack.org/#/c/236712/
20:06:07 <flaper87> ttx: that's like amazon's one-click: DANGEROUS
20:06:09 <flaper87> :P
20:06:24 <ttx> flaper87: no kidding
20:06:32 * ttx looks behind him to find 3 snowboard vests
20:06:41 <flaper87> O.O
20:06:47 <ttx> This one is also pretty consensual
20:06:53 <ttx> Last chance to complain or post your approval...
20:07:00 <flaper87> even twitter agrees with this one
20:07:07 <annegentle> yeah
20:07:27 <ttx> alright then, approving
20:07:38 <ttx> fwiw thingee has been working on forming a cross-project liaisons team to get clearer approval from projects
20:07:46 <ttx> thingee: could you give us a quick update on that?
20:07:53 <thingee> hi
20:08:09 <thingee> so we formed a team which is the cross-project spec liaisons http://docs.openstack.org/project-team-guide/cross-project.html
20:08:21 <flaper87> ++
20:08:26 <ttx> To clarify the roles, should we give that team RollCall+1 and then keep Workflow+1 to the tc (or tc chair once discussed here) ?
20:08:30 <rockyg> ++
20:08:48 <ttx> trying to find a way to get their vote to stick
20:08:58 <thingee> this group will be representing a project and watching the cross-project repo for new specs. Basically approve or comment, or bring someone within their project that would have knowledge on the request
20:09:27 <thingee> this should further help the TC to make sense of consensus before stamping things
20:09:56 <flaper87> I think giving them RollCall is fine
20:09:57 <thingee> and give us people we can contact on projects that are watching such initiatives. This helps TC, product working group, etc
20:10:07 <dhellmann> ttx : roll-call vote seems appropriate
20:10:11 <ttx> thingee: would adjusting the ACL as I suggested above help or hurt ?
20:10:16 <flaper87> Hope that will also encourage the team to focus more on those reviews, report back to their teams and what not
20:10:21 <jeblair> so we are disavowing cross-project specs as TC-level items?
20:10:31 <dhellmann> no, just adding more reviewers
20:10:32 <ttx> dhellmann: we could even keep tc members in that rollcall vote, sounds appropriate
20:10:38 <dhellmann> jeblair : want projects to actually look at these things
20:10:42 <dhellmann> oops, *we
20:10:43 <jeblair> dhellmann: i want that too
20:10:47 <jeblair> and i'm fine with it
20:10:55 <dhellmann> that's what the new liaison group is for
20:10:58 <jeblair> however, i don't think we can just add more voting members to the tc
20:11:01 <thingee> ttx: I'm fine with this to help the TC make more sense of who from this group is voting
20:11:04 <dhellmann> ttx: yes, I would definitely keep tc
20:11:12 <thingee> this is the current group so far https://wiki.openstack.org/wiki/CrossProjectLiaisons#Cross-Project_Spec_Liaisons
20:11:28 <ttx> jeblair: those specs are already not a "vote" since we require consensus on them
20:11:34 <jeblair> so it seems perfectly fine to me to say we want to run that repo that way, but i don't think we can do it and consider it as producing things that are on the level of tc resolutions at the some time
20:11:40 <ttx> so it's not as if you were counting them
20:11:59 <jeblair> ttx: i thought they held the same sway as anything else the tc votes on
20:12:28 <ttx> jeblair: sure but since we required consensus before voting on them the votes all went in the same direction
20:12:32 <jeblair> ttx: i understand that there is a group of people who no longer feel that's the best way.  and i don't necessarily disagree.  i just think it's a change and it's worth acknowledging it as such.
20:12:40 <lifeless> me too; we had that partial discssion about this last week
20:13:19 <flaper87> I think the vote from this liaisons is important as they bring knowledge and info from their projects
20:13:30 <flaper87> I'd like to see a formal way for them to express agreement
20:13:38 <ttx> jeblair: yeah, I agree it's a bit unclear at this stage and that the proposed ACL would be a change
20:13:39 <jeblair> flaper87: i agree.  i love this idea.  i want us to understand the implications
20:13:42 <flaper87> (after having discussed things with their own team)
20:14:04 <flaper87> Is there a way for us to express this in gerrit in a way that doesn't look like vting ?
20:14:06 <ttx> maybe we could have a resolution on how cross-project specs should be handled from now on, that would clarify
20:14:06 <flaper87> voting,even
20:14:21 <ttx> so that we are sure we are all on the same page
20:14:29 <ttx> and see all the implications
20:14:40 <ttx> and have a reference doc for when we change it in the future
20:14:49 <dhellmann> that would also give us a place to document that we consider them binding
20:14:53 <ttx> (last time we had that discussion we didn't document it)
20:14:56 <jeblair> ttx: couldn't hurt.  i just want us to be clear as to what the tc is voting on under the authority granted by its charter and what's not.
20:15:29 <ttx> the charter gives the tc the power to override decisions anyway
20:15:46 <ttx> the question is more, how to make the best progress on those specs
20:15:47 <jeblair> dhellmann: i think that if the tc does not officially vote on them we can not consider them binding in the same way we consider tc resolutions.
20:15:56 <ttx> jeblair: agreed
20:15:58 <flaper87> also, approval should be kept just for the TC seat/mod/etc
20:16:05 <jeblair> that doesn't mean they aren't good ideas and that the project shouldn't adhere to them absent anything else :)
20:16:30 <dhellmann> jeblair : ok, I guess I don't understand why giving more people RC+1 on that repo means we can't vote, too?
20:16:34 <ttx> thingee: how about when the group is formed you place a resolution describing how we should handle cross-project specs from now on, and have the TC vote on that
20:16:38 <ttx> that would clarify
20:17:00 <flaper87> sounds like a good step forward
20:17:09 <flaper87> we can discuss this more over that review
20:17:10 <thingee> sure
20:17:20 <jeblair> dhellmann: if you consider that repo as having the authority of the tc as under its charter, it would effectively be adding people to the tc by appointment which i don't think the tc can do.
20:17:49 <dhellmann> jeblair : but nothing would be approved there before we voted.
20:18:00 <ttx> jeblair: to be fair, the TC has +2/W+1 on that cross-project specs repo mostly as a default solution, not by charter or design
20:18:00 <jeblair> dhellmann: the RC column is how we vote
20:18:12 <flaper87> jeblair: can we give them +2 but no RC ?
20:18:13 <jeblair> ttx: your understanding of that differs from mine
20:18:20 <dhellmann> jeblair : that's true today. it's not the only way to vote, though.
20:18:23 <ttx> jeblair: I'll unearth the logs
20:18:23 <flaper87> right now cp specs just have votes
20:18:52 <jeblair> dhellmann: well, i mean sure we can create more columns or whatever, but the RC field is what we created specifically for our official votes
20:18:53 <ttx> ok, let's say the next step here is to have a resolution to clarify how approval of cross-project specs should be conducted
20:19:16 * flaper87 proposes adding a Liaison-Call column
20:19:16 <jeblair> ttx: i carefuly set up the acls according to the understanding i had at the time which is that it should support official TC votes
20:19:18 <thingee> ttx: can I just add this to the project team guide for cross-projects?
20:19:20 <jeblair> ttx: so it's not happenstance
20:19:27 <ttx> #action ttx to dig in meeting log history to uncover the history behind the current CP specs approval system
20:19:42 <dhellmann> thingee : no, we need it in the governance repo
20:20:04 <ttx> #action thingee to propose a resolution to describe how cross-project specs should be approved
20:20:29 <ttx> thingee: the PTG derives practical information from governance
20:20:35 <ttx> not the other way around
20:20:45 <thingee> ok, so I guess for now the TC can hear me out on how many projects voted until we have something more formal in place?
20:20:52 <thingee> I'd rather not delay this groups work
20:20:52 <ttx> thingee: yes
20:21:07 <ttx> for now we keep the old system, we vote
20:21:31 <thingee> ok
20:21:33 <ttx> ok, we have a next step there, moving on to next topic
20:21:36 <ttx> thingee: thanks!
20:21:49 <ttx> #topic Deprecate the use of the term "Stackforge"
20:21:55 <ttx> #link https://review.openstack.org/265352
20:22:02 <ttx> Apparently keeping the word "stackforge" around results in more confusion than clarity
20:22:10 <ttx> So the proposal is to remove it completely
20:22:15 <flaper87> ++
20:22:18 <jeblair> yeah, we gave it a go but it's not working out
20:22:21 <ttx> and it has enough votes to pass now
20:22:28 <dhellmann> the king is dead, long live the king
20:22:36 <flaper87> lol
20:22:39 <ttx> approving in a few seconds
20:22:44 <jeblair> dhellmann: ++
20:22:45 <flaper87> 3... 2... 1...
20:22:54 <ttx> "unofficial" is certainly less ambiguous
20:23:00 <ttx> approved
20:23:03 <lifeless> so I agree with the thing
20:23:08 <lifeless> I have a procedural question
20:23:11 <lifeless> which I put on the review
20:23:12 <ttx> lifeless: oops
20:23:16 <lifeless> -> should it be a new resolution ?
20:23:25 <flaper87> what thing?
20:23:28 <flaper87> stackforge?
20:23:30 <ttx> lifeless: that is a good question
20:23:30 * flaper87 confused
20:23:31 <lifeless> like; the prior resolution was made
20:23:35 <lifeless> its dated
20:23:40 <flaper87> ah, gotcha
20:23:43 <lifeless> this isn't an editorial fix like a typo
20:23:46 <ttx> I think it's more of an adjustment than a new decision
20:23:49 <lifeless> its a semantic change
20:23:59 <jeblair> good question, and surprisingly, perhaps, i don't have an opinion :)
20:24:13 <lifeless> if it was a living document, like the PTI, it would be clearly appropriate to edit in situ
20:24:17 <dhellmann> maybe we should add an "updates" section to the bottom of the document
20:24:29 <ttx> lifeless: we could have a resolution that says "we discontinue usage of the term stackforge" and then adjust the text of old resolution to match
20:24:32 <lifeless> dhellmann: that would work
20:25:04 <ttx> I agree it's a bit weird to edit the text of a 2015 resolution
20:25:08 <lifeless> note that because we're publishing this as html for reading, that 'read the git history' isn't a hugely satisfying answer, to me at least
20:25:39 <jeblair> so perhaps a new resolution is in order, then append a link to it to the original?
20:25:53 <flaper87> jeblair: ++
20:25:54 <fungi> this also isn't the first standing resolution to have subsequent modifications of some significance, i think? though i'd need to dig for other examples. it has struck me as an odd pattern as well
20:25:58 <ttx> jeblair: we could say that resolutions are immutable
20:26:17 <flaper87> I think it's a good moment to fix this process
20:26:21 <ttx> I'll go back in history and check what else we have
20:26:22 <flaper87> I like resolutions being immutable
20:26:24 <dhellmann> #link https://review.openstack.org/269850 add changes section to resolution
20:26:38 <rockyg> yeah.  a "superceded by" like RFCs
20:26:43 <flaper87> (except for typos and trivial fixeS)
20:26:50 <fungi> i mean, to me the resolution is the thing that was voted on, and later updates, even small corrections, weren't considered in that vote (or necessarily even voted on by the same people)
20:27:12 <ttx> we'll likely want the doc site to react accordingly though
20:27:21 <ttx> so that will require some extra thought
20:27:54 <fungi> 269850 looks like a reasonable compromise
20:27:56 <dhellmann> ttx: add superseded to the title?
20:28:14 <ttx> dhellmann: it's likely to make a busy index after some time, but yeah, something like that
20:28:22 <jeblair> i think generally immutable, but being able to add 'superceded by' or 'ammended by' or something would be helpful.
20:28:31 <dhellmann> ttx: we could also move them to a separate part of the toctree
20:28:33 <flaper87> ++
20:28:48 <edleafe> dhellmann: +1
20:28:52 <ttx> dhellmann: yes, I thought about something like that
20:29:10 <edleafe> archive for old, superseded resolutions
20:29:20 <ttx> dhellmann: I'd rather have superseded resolutions than a changes section
20:29:35 <ttx> basically the reference/ directory is for changing reference documents
20:29:41 <dhellmann> ttx : this isn't really superseded, though, it's just amended
20:29:47 <ttx> resolutions are approved bits of text
20:29:58 <ttx> if we change the approved bit of text we file a new resolution
20:30:05 <dhellmann> ok
20:30:06 <flaper87> yup
20:30:08 <ttx> and superseded the old one
20:30:23 <ttx> I think it's rare enough to justify it
20:30:29 <ttx> and makes the date on them look less funny
20:30:36 <dhellmann> so jeblair will file a revert of https://review.openstack.org/#/c/265352/ and then a  new resolution?
20:30:48 <lifeless> +1
20:30:51 <ttx> dhellmann: in the same change, yes
20:30:57 <dhellmann> right
20:31:05 <ttx> Not really a new vote, more like a typo fix
20:31:14 <jeblair> happy to -- should i do that by copying the whole text, or should i write something that says "the stackforge retiremest resolution is ammended to read..." ?
20:31:17 <fungi> or a resolution could be separate from the document being updated? the resolution is stating tha the document should be updated to convey whatever new thing and then the document can be updated in the same change which adds the file for the resolution
20:31:18 <dhellmann> should we do that now?
20:31:27 <ttx> jeblair: full text I would say
20:31:33 <dhellmann> jeblair : summarize the change and add the new full text
20:31:41 <flaper87> full text
20:31:47 <fungi> still feels like in some ways a revision control system is being reinvented, poorly, but i suppose that's more or less the point
20:32:07 <jeblair> fortunately, we try to have reference docs when we can
20:32:16 <jeblair> so this only comes up when we want to express abstract ideas :)
20:32:21 <ttx> yeah, resolutions are rare
20:32:28 <jeblair> i'll try to do the update now
20:32:45 <ttx> we did 850 changes in governance in 2015, and there is only a dozen resolution total
20:33:06 * fungi guesses 90% were updates to reference/projects.yaml
20:33:10 * ttx moves on to next topic, let's go back to that in open discussion
20:33:12 <ttx> 99%
20:33:20 <ttx> #topic Make constraints opt in at the test level
20:33:25 <ttx> #link https://review.openstack.org/267149
20:33:31 <ttx> This was posted as an alternative to https://review.openstack.org/#/c/266625/
20:33:38 <ttx> So you might want to familiarize yourselves with that review before approving
20:34:10 <ttx> I think I prefer sdague's approach to the problem, but I can be easily convinced
20:34:40 <sdague> right, this came up in trying to take the final step on constraints in the nova repo
20:34:46 <ttx> I see lifeless is fine with it
20:35:03 <ttx> lifeless: does that mean you will abandon https://review.openstack.org/#/c/266625/ ?
20:35:23 <sdague> we spent 3 years getting rid of run_tests.sh (which only happened this month), changing interfaces on people again seemed suboptimal
20:35:50 <lifeless> ttx: yes; I have no particular interest in how 'use constraints' is spelt
20:35:56 <lifeless> ttx: the benefit is in the use, not the spelling
20:36:06 <ttx> we have 7 votes now, can approve unless there is a last-minute objection
20:36:10 <ttx> lifeless: agreed
20:36:24 <jeblair> sdague: i have made an attempt to make "tox" more useful by proposing this change to nova: https://review.openstack.org/267140  it seems like it may be difficult to get consensus
20:37:12 <sdague> jeblair: my preference is still to not bifurcate here, it caused enough confusing in the month we did in devstack before we gave up and deleted the non constraints code
20:37:22 <jeblair> on a technical note -- some not insignificant work does have to happen in infra to effect that change (since we're effectively inverting the meaning of a significant portion of our config)
20:37:31 <jeblair> sdague: that was not an argument against it
20:37:46 <ttx> jeblair: if it's not a NO vote, I'll approve now
20:37:58 <jeblair> ttx: it is not a no vote
20:38:06 <jeblair> sdague: i think we can switch to constrints by default and still make 'tox' useful
20:38:22 <ttx> approved
20:38:23 <dhellmann> jeblair : can you elaborate on the infra changes you expect to need?
20:38:33 <fungi> job configs
20:38:33 <sdague> jeblair: https://review.openstack.org/#/c/267133/2/jenkins/jobs/python-jobs.yaml I thought that mostly covered it?
20:38:55 <dhellmann> fungi : those jobs run "tox -e py27" right? why would that need to change?
20:39:15 <fungi> dhellmann: they need to provide the constraints file
20:39:22 <fungi> which the change sdague linked does
20:39:24 <dhellmann> oh, I thought the tox.ini changes did that
20:39:43 <jeblair> sdague: that's the bulk.  without further changes it will mean that we'll be cloning the requirements repo on every python job run whether it's used or not.
20:39:46 <sdague> dhellmann: the tox.ini changes provide a git url, and an override from the env
20:39:58 <fungi> dhellmann: in a way which respects the environment variables being set by zuul
20:40:04 <clarkb> jeblair: though in theory that is low overhead due to the git repo cache
20:40:08 <sdague> the override is always exported by zuul now, even if it doesn't exist
20:40:13 <jeblair> sdague: afaik, no one has done the work to figure out what kind of a performance impact that will have.  of course, we can just try it in production and see.  :)
20:40:29 <ttx> jeblair: and revert the whole idea if that proves catastrophic
20:40:35 <fungi> which is a valid enough answer. we do that with job templates semi-regularly
20:40:47 <lifeless> so
20:40:49 <sdague> sure, though it will mean not having to have 2 sets of jobs on projects, so we'll save there
20:40:57 <lifeless> we were expecting the bulk of jobs to be constrained eventually anyway
20:40:58 <fungi> the bindep implementation will need a similarly shotgun transition
20:41:26 <lifeless> so I don't see the performance aspect really being a thing, except for unofficial projects, perhaps
20:42:03 <ttx> ok, let's move on to the next topic
20:42:08 <jeblair> lifeless: i agree, it should mostly affect those
20:42:20 <sdague> ok, so we're approved now, which means we can get reviews on https://review.openstack.org/#/c/267133/2/jenkins/jobs/python-jobs.yaml to move forward, right?
20:42:22 <fungi> yeah, projects whose python dependencies are at odds with the constraints list will either need to fix that or have their own special non-constraints jobs added
20:42:45 <lifeless> fungi: or accept the minor overhead of cloning requirements
20:43:02 <sdague> lifeless: ++ right that
20:43:13 <ttx> that sounds reasonable
20:43:38 <dougwig> "i wish the py27 job finished quicker", said no one, *ever*, while staring at a see of dsvm jobs.
20:43:44 <sdague> dougwig: ++
20:43:50 <ttx> ok, moving on, we can go back to that in open discussion if needed
20:43:52 <ttx> #topic Clarification of licensing requirements
20:43:53 <mordred> dougwig: ever is a strong word ..
20:43:57 <ttx> #link https://review.openstack.org/268017
20:44:06 <ttx> This one is the result of a looong discussion with the Foundation legal counsel
20:44:08 <mordred> o/ btw
20:44:19 <russellb> ttx: thanks a bunch for driving that
20:44:20 <ttx> to translate the language in the bylaws and the current situation we have into a set of clear licensing requirements
20:44:28 <russellb> really nice improvement
20:44:30 <ttx> I came up with a text that he finally agreed with and that is IMHO compatible with the current oral tradition
20:44:44 <mordred> I like how clear the document is
20:44:48 <ttx> I propose we approve that one and improve it over time
20:44:51 <russellb> oops, i forgot to vote
20:44:53 <dhellmann> ttx: I proposed some further clarifications on top of that patch
20:45:03 <ttx> dhellmann: yes, I'll also propose a subsequent change to clarify that test-only dependencies follow the rules for "infrastructure" rather than the rules for runtime dependencies
20:45:06 <dhellmann> adding some links, removing a few pronouns
20:45:08 <flaper87> no objections here
20:45:12 <ttx> since we have MySQL-python and pylint that are GPL in there
20:45:15 <ttx> but I'll need to pass the new wording through the lawyer first
20:45:35 <ttx> but first things first, let's get the approved wording in as a base
20:45:52 <russellb> lifeless: re: your question, read the section about dependencies, it says GPL is fine.
20:45:53 <ttx> missing a couple votes
20:46:00 <mordred> ttx: we've moved to pymysql which is not GPL
20:46:09 <lifeless> russellb: wait, I read it as saying its -not-
20:46:25 <russellb> oh, i can't read
20:46:26 <mordred> ttx: and pylint is not a dependency of the release - it is a tool used to produce the release
20:46:27 <lifeless> russellb: line 23
20:46:29 <ttx> lifeless: I need to add a paragraph on test deps
20:46:34 <mordred> and tools used to make the release are fine to be GPL
20:46:49 <mordred> ttx: I thought they were covered in the infra section nicely personally
20:46:52 <ttx> mordred: right, it's just unclear that test deps are infrastructure
20:46:56 <mordred> ttx: ++
20:46:58 <ttx> I'll clarify that
20:47:00 <mordred> ttx: I agree - that could be clearer
20:47:13 <lifeless> so, I'd welcome some clarification, but I agree that you'd need to want to read it poorly to be confused right now
20:47:16 <dhellmann> russellb : I did the same thing, hence https://review.openstack.org/#/c/269823/1
20:47:20 <russellb> dhellmann: thanks
20:47:27 <lifeless> something like 'dependencies for deployed use' or something
20:47:35 <ttx> lifeless: I'll clarify, just need to get the new new wording past the lawyer again :)
20:47:38 <lifeless> lets not bake test-requirements.txt into the doc or something
20:47:44 <mordred> lifeless: ++
20:47:46 <lifeless> because we're going to be deleting that file soon I hope
20:48:19 <ttx> as part of this exercise I also went through all deps to find licnesing
20:48:25 <ttx> https://review.openstack.org/#/c/264754/
20:48:42 <ttx> fun fun
20:48:58 <russellb> i saw that via lots of global requirement sync commits :)
20:48:58 <flaper87> ttx: ah-ha, it was you
20:49:04 <sdague> ttx: ah, that's why that synced out
20:49:08 <flaper87> LO
20:49:09 <flaper87> L
20:49:10 <angdraug> I'm probably reading it poorly but doesn't "dependencies" ultimately include KVM and Linux kernel?
20:49:34 <ttx> sdague: yes, would be good to enforce that new entries are provided with licensing
20:49:40 <dhellmann> angdraug : we don't link against the kernel
20:49:40 <russellb> angdraug: fair point, that could be clarified
20:50:00 <angdraug> dhellmann: you're assuming GPL's interpretation of "derivative work"
20:50:11 <russellb> i think that's worth a clarification.
20:50:16 <flaper87> clarification wouldn't hurt
20:50:16 <angdraug> it's a good assumption to make, but I think it would be better to spell it out
20:50:30 <ttx> feel free to suggest improvements
20:50:41 <ttx> We have 7 votes in, I'll approve that one now unless someone objects
20:50:46 <russellb> i still think as proposed it's a great start and worth approving
20:50:53 <jeblair> this looks pretty good to me.
20:50:54 <russellb> better than current situation by 1000x
20:50:54 <ttx> it's a reference doc, not a resolution :)
20:50:57 * flaper87 looks around and notices everyone is happy
20:51:33 * ttx approves then
20:51:35 <russellb> i'm not happy
20:51:44 * ttx hugs russellb
20:51:44 <russellb> but that's unrelated
20:51:46 * flaper87 gives russellb a bag of candies
20:51:48 * dhellmann hands russellb some chocolate
20:51:48 <russellb> <3
20:51:54 <ttx> #topic Open discussion
20:51:59 * mordred hands russellb a mostly unmuddy sheep
20:52:02 <ttx> Next week I might be unavailable due to travel
20:52:05 <lifeless> russellb: why aren't you happy?
20:52:08 <ttx> read: beach
20:52:11 <jeblair> ttx: anywhere fun?
20:52:11 <russellb> our mission statement update proposal is on the board meeting agenda for next week
20:52:15 <fungi> glad to see the infrastructure projects specifically called out in our licensing requirements, finally
20:52:16 <ttx> There is also a board meeting around the meeting time
20:52:16 <russellb> it will be discussed and voted on by the board
20:52:23 <ttx> jeblair: I'm ashamed
20:52:33 <ttx> That said we have a backlog of things to process, so if someone volunteers to chair we could still have the meeting
20:52:43 <fungi> i also wonder if that indirectly absolves us of using the cla for infra projects? ;)
20:52:44 <flaper87> I can help
20:52:45 <ttx> I'll prepare the agenda and all, it's just that I'm not sure if I'll be around at meeting time
20:52:57 <ttx> fungi: indirectly yes
20:52:58 <flaper87> ttx: in case you're not around
20:53:08 <flaper87> Also, we should write a new blog post
20:53:19 <ttx> #info flaper87 volunteers to chair if ttx can't make next week meeting
20:53:22 <fungi> i mean, if the cla is only relevant to apache-licensed projects and we're free to have non-apache-licensed projects for infra, then...
20:53:29 <flaper87> I think 2 should come out soon, TBH. The linux image resolution thing deserves detailed explanation
20:53:31 <sdague> next week is also nova midcycle, in .eu, so I suspect a slice of us are going to be drinking during this time period
20:53:43 * russellb has been using SIgned-off-by headers for several months :)
20:53:46 <ttx> sdague: I'm fine with skipping too
20:53:50 <ttx> one less thing to worry about
20:53:53 <annegentle> flaper87: I can help with blog post
20:54:06 <annegentle> sdague: heh, drink well
20:54:07 * flaper87 should start using Signed-Off-By
20:54:13 <ttx> so.. skip or meet?
20:54:22 <lifeless> hmmm, I want git review's commit hook to add s-o-b
20:54:28 <flaper87> well, who's going to be around ?
20:54:29 <sdague> I do not expect to make it next week
20:54:34 <annegentle> I'm around
20:54:48 * dtroyer is around too
20:54:52 <sdague> lifeless: the point is it should be deliberate and intentional, otherwise it's not as meaningful
20:55:03 <ttx> sdague: me neither. 3pm I likely be on the beach
20:55:20 <lifeless> sdague: for anything I'm creating here, its deliberate and intentional :)
20:55:21 <mordred> lifeless: I want the same thing
20:55:34 <ttx> ok, I'll move that discussion to the openstack-tc ML
20:55:39 <mordred> sdague: but it's never going to be that - becuase people are just going to make a bash alias anyway
20:55:41 <lifeless> mordred: git commit -s, of course
20:55:42 <jeblair> sdague: personally, i think it's legitimate to say "i deliberatly acknowledge every commit i make to this repo is made under the terms of the dco" :)
20:55:44 <mordred> lifeless: right
20:55:52 <mordred> jeblair: ++
20:55:52 <ttx> #action ttx to sync if we have enough people for a meeting next week on openstack-tc
20:55:57 <annegentle> thanks ttx
20:56:00 <mordred> I don't mind if I need to set something per-repo
20:56:02 <flaper87> Also, I'm planning to send out an email w.r.t the stabilization cycle later toda/tomorrow. It's mostly to kick off the discussion, get feedback and propose a next step forward
20:56:05 <ttx> anything else?
20:56:07 <mordred> I just don't wnat to have to remember to add -s to my command line
20:56:11 <flaper87> just a heads up
20:56:17 <ttx> jeblair: did you post your resolution amendment thing ?
20:56:27 <jeblair> ttx: no i'm still typing; this has been an exciting meeting.
20:56:37 <jeblair> probably not going to make the end of meeting
20:56:45 <ttx> jeblair: no hurry, we can process that in time
20:56:51 <fungi> lifeless: sdague: yeah, there was already concern expressed by some on the foundation legal team (maybe just one person) that devs would invalidate our use of the dco by adding s-o-b to their git configs without realizing why they were doing so
20:57:05 <ttx> jeblair: not as if it was the first time we rewrote history
20:57:18 <russellb> fungi: it's in our dev manual at least
20:57:18 <clarkb> mordred: I am pretty sure you can set a git config flag that will just do it
20:57:28 <fungi> russellb: yep! thanks for adding that ;)
20:57:40 <fungi> provides a great counterargument
20:57:47 <russellb> yeah that was the idea
20:57:48 <clarkb> mordred: format.signOff
20:58:04 <lifeless> clarkb: +1
20:58:09 <russellb> i don't like automating it myself, because i like to only add it when i'm really ready to submit something, not while it's still WIP
20:58:10 <flaper87> clarkb:++
20:58:20 <russellb> but that's just my own pedantry ...
20:58:20 <mordred> clarkb: oh! that's new!
20:59:03 <fungi> there will eventually be a bit of a discussion, i'm sure, when we get ready to switch to requiring s-o-b and drop the icla check
20:59:18 <ttx> should be fun
20:59:27 <ttx> I think I already exceeded my lawyering quota though
20:59:32 <fungi> since we can't really do them both, no mix-or-match, it's an all-or-nothing switch
20:59:59 <fungi> i mean, we can do it per repo, either cla or dco, but can't enforce a mix on a single repo
21:00:05 <ttx> and we are out of time. Thanks everyone!
21:00:35 <flaper87> o/
21:00:37 <russellb> bye
21:00:37 <ttx> #endmeeting