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