17:00:14 <gouthamr> #startmeeting tc
17:00:14 <opendevmeet> Meeting started Tue May 20 17:00:14 2025 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:14 <opendevmeet> The meeting name has been set to 'tc'
17:00:25 <gouthamr> Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct.
17:00:29 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
17:00:32 <gouthamr> #topic Roll Call
17:01:15 <mnasiadka> o/
17:01:20 <gouthamr> noted absence: c a r d o e,   s p o t z,   f r i c k l e r
17:01:33 <noonedeadpunk> o/
17:01:47 <gouthamr> courtesy ping: gmaan, gtema, bauzas
17:01:54 <gmaan> o/
17:02:22 <bauzas> here but on another meeting
17:05:13 <gouthamr> we've a smaller-than-usual crowd today.. lets get started
17:05:21 <gouthamr> #topic Last Week's AIs
17:05:42 <gouthamr> i don't think we took many..
17:06:19 <gouthamr> we spent a while discussion governance proposals on gerrit, and the discussion continued in the respective patches
17:06:53 <gouthamr> these have been updated, and could use reviews
17:07:07 <gouthamr> #link https://review.opendev.org/q/project:openstack/governance+status:open (Open reviews on the governance repo)
17:08:07 <bauzas> ack
17:08:53 <gouthamr> a couple of other AIs pertain to topics we're discussing today
17:09:11 <gouthamr> contributor experience, and the topic regarding ICLA/DCO
17:09:32 <noonedeadpunk> Am I right that we never heard back from person who asked for quantum?
17:09:51 <fungi> i don't think they were asked any questions
17:09:55 <gouthamr> i did
17:09:59 <gouthamr> privately
17:10:19 <noonedeadpunk> did you get any responce
17:10:20 <gouthamr> i sent them an email 21 hours ago, stating this:
17:10:20 <gouthamr> "A member of the OpenStack Technical Committee wanted you to comment
17:10:20 <gouthamr> on, or support this request with a "+1":
17:10:20 <gouthamr> https://review.opendev.org/c/openstack/governance/+/949783/comments/087aa18a_d00f2fcf
17:10:22 <gouthamr> Would you be able to do that? You would need to sign up for an account
17:10:22 <gouthamr> on https://review.opendev.org. If you're not comfortable doing that,
17:10:24 <gouthamr> feel free to share any insights on the mail thread, and we'll still
17:10:24 <gouthamr> consider it your position."
17:10:42 <gouthamr> no response yet
17:11:59 <gmaan> nit irrespective of their response/question, proposed resolution is good way to give go ahead from us.
17:12:08 <gmaan> implementation can be done now or later depends on need
17:12:21 <gouthamr> i was going to jinx by stating the same thing :)
17:13:00 <gouthamr> this resolution has gathered enough RC votes to merge.. it was last updated a week ago
17:13:05 <gmaan> ++
17:13:11 <noonedeadpunk> Well, I mean, won't it be weird situation to have a resolution and get stuck with it?
17:13:22 <gouthamr> stuck with?
17:13:36 <noonedeadpunk> as if we won't transfer control, it would be weird to have it
17:13:37 <gouthamr> you mean if the person doesn't want this anymore?
17:13:40 <noonedeadpunk> yeah
17:13:51 <gouthamr> ah, we
17:13:56 <gouthamr> have clarified the next steps
17:14:00 <JayF> I think you all sometimes underestimate how much of a barrier it is to folks to signup for all the accounts needed to vote on a change in gerrit
17:14:00 <gmaan> than it can be used as approval/ref for future if anyone need
17:14:01 <gouthamr> they can delete the project if they wish
17:14:21 <JayF> That said, I would not take their lack of gerrit participation as a sign of disinterest
17:14:21 <clarkb> JayF: not only that but what value does doing so add here? they already made the request why do they need to approve the request again?
17:14:27 <noonedeadpunk> JayF: and reply to email thread they've started?
17:14:28 <JayF> clarkb: ++
17:14:30 <gouthamr> JayF: i didn't, which is why i suggested they just respond on the mail thread they started
17:14:37 <clarkb> even if they already had a gerrit account it feels superfluous
17:14:40 <JayF> gouthamr: ah, I misread
17:14:41 <gmaan> clarkb: ++
17:15:31 <fungi> it's way more red tape than we went through when we handed over reddwarf a few months ago, fwiw
17:15:53 <gmaan> resolution/merging it etc are internal way to support their request, we do not need them to re-confirm on multiple places
17:16:31 <fungi> w're squatting tons of project names on pypi we never used, would be a pain to keep going through this for every one
17:16:33 <gouthamr> i agree, however, multiple people on the TC expressed the desire to formalize this.. and i respect that
17:16:54 <gouthamr> i don't know if we'd care about all of the other names the same way
17:16:58 <noonedeadpunk> it's probably me spoiled by my wife who made her carrer at risk&abuse verifying customers and their requests for domain names transfers :D
17:17:43 <fungi> maybe quantum is "special" in some way and we don't need to engage in this level of debate for other project names we're not using
17:17:46 <noonedeadpunk> so I'm inventing smth which is totally unnecessary here
17:18:07 <noonedeadpunk> yeah, right
17:19:12 <gouthamr> any other AIs to discuss/
17:19:46 <gouthamr> lets move on
17:19:46 <gouthamr> #topic CLA to DCO
17:19:46 <gouthamr> #link https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/thread/PXMTX67TRL2B4ONICTT2E2XZLG4J4LAL/
17:20:06 <gouthamr> jbryce _may_ be here..
17:20:20 <jbryce> i am!
17:20:28 <gouthamr> #link https://developercertificate.org/ (Developer Certificate of Origin)
17:20:35 <gouthamr> hey there jbryce
17:21:00 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/A7S24NMKOQZFXRAAEEYQX23S6UF4WML2/ ([tc][all] Moving from CLA to DCO for OpenInfra Contributions)
17:21:43 <gouthamr> this move comes to us from the LF transition discussions that have been occurring within the OpenInfra board for the past few months
17:22:15 <bauzas> looks to me a good change
17:22:20 <gouthamr> jbryce noted that the change would be part of the "broader transition into the Linux Foundation and could take effect starting June 1, 2025"
17:22:29 <gouthamr> so we have a timeline too ^
17:22:57 <gouthamr> ttx pointed us to the old TC resolution to this regard
17:23:01 <gouthamr> #link https://governance.openstack.org/tc/resolutions/20140909-cla.html
17:23:25 <gmaan> Even this was resolution for request from TC to board
17:23:26 <gouthamr> but, i don't have context of what happened between then and now to judge if we need to re-litigate this
17:23:39 <jbryce> what we would need from the TC is a re-confirmation that the TC still wants to go this direction since it's been a decade plus. preferably in the next 2 weeks so we can make it effective June 1
17:23:46 <gmaan> and this time is coming from board which matches both side desire to move to DOC
17:23:54 <noonedeadpunk> Yeah, I think the question here not about switching or not, but how to do that in a most smooth for contributors way
17:23:55 <gmaan> jbryce ++
17:24:10 <gmaan> I think a new resolution  (confirming the board recommendation this time) can also be helpful as it provide way for community members to express their opinion as formal way (in favor or against)
17:24:12 <gouthamr> i don't think it can be smooth
17:24:21 <jbryce> i think the main thing that has happened is that the DCO has a much longer history and the board was generally supportive of adopting it this time around
17:24:32 <fungi> note that the effective date would basically be permission to start the process of switching over on the tc/openstack's preferred timetable, it would not need to be an immediate cut-over
17:25:09 <bauzas> while I'm fine with the move forward, I wonder about the interim period
17:25:09 <gouthamr> how would it look if it wasn't an immediate cut-over?
17:25:31 <noonedeadpunk> fungi: but can we distinguish DCO from CLA user in CI?
17:25:46 <fungi> ci doesn't come into the picture
17:25:52 <fungi> we enforce it with gerrit permissions
17:25:55 <gmaan> yeah
17:26:07 <noonedeadpunk> oh, ok
17:26:18 <gouthamr> JayF noted earlier that gerrit enforcement is CI according to the developer "UX" :D
17:26:24 <noonedeadpunk> so if no signed-off in commit message but user has signed CLA - it is fine?
17:26:26 <fungi> once we have the all-clear to make the switch, we can start making people aware it's coming, prepare changes to documentation, and so on
17:26:27 <clarkb> the current Gerrit permission checks membership against the icla group. With DCO you configure gerrit to require the signed off by message footer in the commit message on push
17:26:27 <gmaan> and it can be valid (I mean format for commit msg) from the new commits
17:26:33 <bauzas> fungi: would it be transparent for our contributors ?
17:26:33 <noonedeadpunk> liek gerrit will pass it?
17:26:40 <JayF> better than CI if it gives feedback on push :D
17:26:51 <jbryce> as far as timing, ideally there would be a clean cutover where no one signs a CLA after May 31
17:26:59 <fungi> bauzas: no, contributors will need to use a different workflow (git commit -s or add a config option to their git tooling)
17:27:01 <clarkb> noonedeadpunk: no it would be one or the other in the requirement. I don't think you can express either is fine in gerrit
17:27:17 <clarkb> (you can require one, the other, or both but not either)
17:27:18 <gouthamr> jbryce: ah, makes sense.. a sunset date to grey out the ICLA
17:27:21 <noonedeadpunk> so it will be immediate cut-off then
17:27:53 <bauzas> Ah, Signed-Off I see
17:28:03 <fungi> we would schedule a date to do that, it wouldn't be the same as the effective date we'd be allowed
17:28:37 <bauzas> then my main concern is again about the deadline we have
17:28:44 <fungi> we have no deadline afaik
17:28:47 <noonedeadpunk> I don't think we have a deadline
17:28:51 <noonedeadpunk> or well, we can define that
17:28:54 <bauzas> cool then
17:29:16 <gmaan> only question I have is, do we need to update existing in-progress commit with  Signed-Off ?
17:29:17 <noonedeadpunk> so we have time to prepare docs, communication, etfc
17:29:34 <fungi> jbryce can correct me if i'm wrong, but we first need the "new" openinfra board under the lf to confirm it's acceptable (or not say it isn't) at their first meeting, though we've gotten tacit approval from the "old" board consistingof the same people
17:29:55 <noonedeadpunk> If it's gerrit ACL, I'd imagine that yes, if one needs to be updated
17:29:58 <clarkb> gmaan: the enforcement is on push so I don't think so. The old code was pushed udner the cla and the new would be under the dco. But jbryce can clarify if there is a legal need to update
17:30:10 <fungi> gmaan: from what i understand, the tc can decide what timeline they want once we get confirmation that it's allowed
17:30:24 <fungi> this isn't a deadline imposed from outside
17:30:41 <jbryce> fungi: no the new governance docs do not require a cla so we don't need a policy update there. i discussed this with our existing counsel as well
17:31:08 <fungi> okay, so as long as we wait for the old foundation to be dissolved we can do it any any point thereafter?
17:31:15 <jbryce> gmaan: i think we can say it would be for contributions post May 31, not existing in process contributions
17:31:30 <gmaan> ++, that will be easy implementation then
17:31:39 <bauzas> ah cool
17:32:00 <jbryce> fungi: no it is not related to the delaware corp at all
17:32:14 <gouthamr> noob question: we'd enforce this on new patches to ongoing/open changes too?
17:32:14 <gmaan> jbryce: maybe something we can explicitly state in board approval? or maybe in TC resolution if we push that
17:32:17 <fungi> if this is still as discussed in the board meeting, we don't have to do the cut-over immediately though, we can continue accepting contributions under the old icla until th etransition has been completed, however long the tc wants that to take, correct?
17:32:47 <fungi> so if they wanted it to be effective starting january 2026, for example, that would still be allowed?
17:32:53 <jbryce> there is no board approval required for it. it's really down to the projects to agree and implement
17:32:58 <fungi> (not that i expect it would take that long)
17:33:24 <jbryce> a january 2026 date would create challenges because we would have to create new CLAs and have contributors post june 1 sign them and then do a switch to dco later
17:33:27 <gmaan> ohk. then fine.
17:34:03 <fungi> wait, so it *does* have to be switched prior to june 1? that seems counter to what was presented previously
17:34:32 <fungi> that doesn't really give any time to update documentation and notify contributors
17:34:34 <JayF> June ... 2025? Like in two weeks?
17:34:40 <noonedeadpunk> that can be problematic then as it's just 10 days to collect the feedback/agreement and prepare docs/recommendations
17:34:52 <gouthamr> the only doc i see that needs updating is this one:
17:34:52 <gouthamr> https://opendev.org/openstack/contributor-guide/src/branch/master/doc/source/common/setup-gerrit.rst
17:34:58 <gmaan> yeah, in 10 days
17:35:05 <bauzas> yeah
17:35:10 <gouthamr> we've not called out CLA/ICLA anywhere else afaik
17:35:15 <fungi> the technical implementation is simple, it could be done now (in a matter of hours anyway), but the human component is not trivial to change
17:35:17 <JayF> gouthamr: And endless internal onboarding documentation which might refer to CCLA/ICLA
17:35:18 <bauzas> that's very short in time
17:35:45 <noonedeadpunk> and sort out for orgs who signed CCLA
17:35:47 <jbryce> yeah i know. unfortunately this is what we realized in the discussion last week. we will have to make a switch to handle the contributions going to a new entity for management
17:36:00 <noonedeadpunk> and if /how they should legally approach changes
17:36:07 * JayF == noonedeadpunk
17:36:14 <jbryce> so it's either new CLAs for the new entity or a switch to DCO (or both sequenced in whatever timeframe)
17:36:15 <JayF> This will require re-evaluation of contribution policies in some orgs
17:36:16 <gmaan> I think once we update the doc/gerrit verification, communication can be done gradually for example, ask in cmt msg review if not done as per DCO
17:36:22 <JayF> and so we should be very careful about taking rapid action
17:36:38 <clarkb> gmaan: gerrit will not let you push unless you do it properly so there won't be anything to ask for in review
17:36:51 <mnasiadka> That's actually an interesting aspect - because knowing legal reality - it might stop some orgs from contributing until they sort out the new reality...
17:37:02 <bauzas> do we really want to block proposals ?
17:37:08 <gmaan> clarkb: perfect, then it is much easy to communiocate
17:37:09 <fungi> what is the legal risk of we don't make the june 1 deadline?
17:37:19 <noonedeadpunk> clarkb: that's why I thought it would be done with zuul kinda, as usually sign-off is checked with some job / github action
17:37:40 <gmaan> it is not block, it is a very easy thing to do. and many commit msg/developer already do the same
17:37:43 <fungi> the "cut over" will be users getting errors when they try to push new changes or revisions to existing changes
17:37:51 <gouthamr> #link  https://gerrit-review.googlesource.com/Documentation/user-signedoffby.html (Gerrit implementation doc)
17:37:54 <clarkb> bauzas: noonedeadpunk: yes its actually an important feature aiui. This way you're only ever looking at content that you are able to accept in the first place
17:38:01 <fungi> errors at the git command line (not ci/webui errors)
17:38:07 <clarkb> it avoids awkward situations where something is pushed that you then have to pretend never existed
17:38:11 <JayF> Ten days is not enough time to allow downstream organizations to react, regardless of if we, upstream, can check all our boxes. Downstream orgs may have to re-engage legal or ospo and update internal documentation.
17:38:20 <jbryce> is it possible to have multiple CLAs active in gerrit? where if someone has accepted the delaware corp version they can continue to contribute but if they haven't they would be presented with an new version for the new entity?
17:38:21 <noonedeadpunk> yeah, right, I agree it's better overall
17:39:12 <fungi> yes, the way gerrit's cla feature works is that as long as users have accepted *a* cla then can continue pushing patches, so they could contribute under the old icla or under a new icla. existing users who have the old icla agreed to would be able to keep pushing patches
17:39:27 <noonedeadpunk> but seems that reality is pointing towards support of check of either old CLA or DCO
17:39:30 <gmaan> I feel this does not require much effort from developer when they push new change. 10 days are even enough to communicate in ML etc :)  Sometime, longer time make communication harder :)
17:39:35 <bauzas> that would be ideal
17:39:57 <noonedeadpunk> gmaan: they may not be _allowed_ by internal policy / legal team
17:40:03 <JayF> gmaan: not my current employer; but I have worked places where I'd have to restart a multi-week process to regain ability to contribute with this kinda change
17:40:04 <gouthamr> to use the DCO?
17:40:04 <noonedeadpunk> it's not that they can't do it
17:40:24 <noonedeadpunk> gouthamr: to push patch outside fo the org
17:40:25 <gouthamr> seems weird, all it says it, i accept whatever license that's on the file i'm editing
17:40:25 <jbryce> ok i can check if that is acceptable legally or if we would need pre-existing contributors to also sign a new CLA for the new entity
17:40:28 <gmaan> Is it? I am not sure DCO are blocked by org.? but I might be wring
17:40:31 <gmaan> wrong
17:40:41 <JayF> gmaan: it's more about the conditions of contribution being laid out in detail in policy
17:40:49 <fungi> however, mixing cla and dco enforcement would require both (agreeing to a cla and adding signed-off-by to their commits)
17:41:02 <JayF> gmaan: if the OSS contribution policy for openstack says "you can contribute as long as you are listed in the ccla", does that means I'm OK to use DCO? These are questions downstreams need to answer
17:41:13 <fungi> so when we turn on dco enforcement it would make sense to turn off cla enforcement
17:41:17 <noonedeadpunk> you might be blocked by your contract as contributions are IP of the comany
17:41:18 <jbryce> agree. if we implement dco, i would not want to mix it with CLA for a variety of reasons
17:41:18 <gmaan> JayF: i see.
17:41:37 <noonedeadpunk> and CCLA could be treated by some as official agreement to push data to
17:41:47 <JayF> noonedeadpunk: that's /exactly/ how  it was treated at the place I'm thinking
17:42:13 <noonedeadpunk> but I'm not a lawyer, and not sure these lawyers are right, but I know that such things totally exist
17:42:27 <noonedeadpunk> right
17:42:39 <JayF> noonedeadpunk: yeah, I agree with you on the vibe it seems like overkill, and isn't even an issue with my current job, but I think we'll freeze people out, especially with only 10 days notice
17:42:46 <gouthamr> we do have a list of CCLA and ICLA signers, can we send an email to each of them indicating this change?
17:42:47 <gmaan> JayF: but if it is coming from the OpenStack community, I feel it is under same umbrellas of following community way of doing the things instead of requiring a new legal check
17:43:03 <gmaan> unless istio past case of changing governance etc but that was a big change from other organization perspective
17:43:25 <jbryce> to summarize, it sounds like the timeline is too short to implement dco by june 1. i will check if we can require new entity CLAs from only net new contributors after June 1 or if we will need all contributors to agree to a new entity CLA even if they had previously agreed.
17:44:29 <noonedeadpunk> I have no idea about my current job, for instance. by I do not all my contributions from the name of the org I'm affilated with... And I totally can do some personal contributions with DCA. But I might need approval from org that I can continue with DCA from their name
17:44:32 <fungi> i'm pretty sure we can hide the old icla when adding a new one, so that new users are presented the new one to agree to, but i would need to test that
17:44:34 <JayF> jbryce: one thing that might also be wise: ensure foundation member companies/reps have done this downstream policy homework in their companies, as well, if that's a lever you can pull
17:45:19 <noonedeadpunk> I'd say if we have to sign new CLA for all who signed old one - better go with DCO
17:45:32 <bauzas> agreed
17:45:36 <noonedeadpunk> as both cases will be equally blockers
17:45:45 <JayF> ++
17:45:51 <noonedeadpunk> and DCO is just eaier/more wise choice overall
17:45:53 <fungi> though to reiterate, if contributors can't contribute to openstack under the dco, then that likely precludes them from contributing to other popular dco-using projects (linux kernel, kubernetes, et cetera)
17:45:54 <bauzas> yeah all is about the upgrade impact
17:46:43 <bauzas> if we expect contributors workflow changes, then please request DCO rather than signing a new CLA
17:46:43 <noonedeadpunk> fungi: it's more about time I guess. And no, k8s is not in the list of projects I can contribute to.
17:46:52 <gmaan> yeah, downstream policy checks valid for new CLA also
17:47:05 <noonedeadpunk> at least through affilation, not as a private person in my free time
17:47:28 <gmaan> DCO makes things easy for developers as downstream checks 3etc
17:47:32 <gouthamr> noonedeadpunk: interesting, has that got anything to do with the kubernetes's licensing or contributor agreement?
17:48:02 <jbryce> noonedeadpunk: i have to check with the lawyers to see if it's possible. i know the current CLA will cover past contributions, but not sure it will cover contributions to the new entity
17:48:07 <noonedeadpunk> it6 has to do with an explicit list of organizations being maintained
17:48:50 <noonedeadpunk> again. I guess it won't be a problem after all, but it might need some time to get approvals
17:49:16 <noonedeadpunk> and also we don't have the strictest rules from what I've heard
17:50:05 <JayF> None of it is hard with sufficient notice; the 10 days is what really makes it difficult.
17:50:11 <noonedeadpunk> ++
17:50:57 <gouthamr> ack, jbryce noted this conclusion, and took an AI
17:51:31 <jbryce> yeah i also wish we would have realized this earlier
17:52:15 <gmaan> meanwhile in parallel, do we want TC to start the formal vote as part of resolution or so?
17:52:15 <noonedeadpunk> maybe we should start writing resolution regardless?
17:52:19 <gmaan> yeah
17:52:34 <gouthamr> how would you resolve something that you've already resolved to?
17:52:59 <gouthamr> i mean, should we call out the CLA changes as well as the DCO enforcement in one go here?
17:53:00 <JayF> gouthamr: the wording of that was very aspirational; a resolution with detail about how to migrate would be additional detail and valuable, I bet
17:53:03 <noonedeadpunk> set a transition date of 1st of june :)
17:53:12 <gmaan> old one is request to board about DCO approval but new one will make confirmation about current requst
17:53:27 <gmaan> and more about transition dates etc
17:53:48 <bauzas> +1 communication is key
17:54:04 <bauzas> a resolution would be the first document
17:54:06 <gouthamr> ack.. we can debate the date after jbryce follows up on this?
17:54:35 <noonedeadpunk> it doesn't sound like there's much choice atm...
17:54:47 <fungi> basically, users should update their workflow/configs asap, and then they won't get their pushes rejected on whatever cut-over date the tc decides on
17:54:48 <bauzas> fwiw, we only have one TC meeting left before June 1
17:54:50 <noonedeadpunk> if we go with path of new CLA - then yeah, we can
17:55:05 <fungi> and we can have documentation updates staged to merge at roughly the same time
17:55:13 <noonedeadpunk> ++
17:55:19 <JayF> fungi: we might wanna communicate to projects to accept patches with the DCO signoff if that's the suggested path
17:55:25 <bauzas> so I guess we need to work on that asap and probably async
17:55:46 <fungi> fair, i didn't know any projects were rejecting it, i've seen lots of users who clearly are just in the habit of doing it already
17:55:56 <gmaan> ++, yeah
17:56:03 <noonedeadpunk> or having it in global git config :)
17:56:07 <bauzas> (I personally have one week left as I'll take some time-off days before June)
17:56:19 <clarkb> JayF: all of that is centrally managed and we don't need their intervention to apply it (even trhoguh normal review processes)
17:56:31 <gouthamr> yes, noone's rejecting it - its been happening in storage projects a while since we have ceph and kubernetes contributors setting a global git config
17:56:41 <bauzas> there are different concerns: one is about the workflow change, the other is company policy
17:56:46 <JayF> clarkb: To be clear: I've seen, in the history of openstack, project reviewers -1 a patch with the only feedback being to remove the DCO signoff
17:56:50 <JayF> clarkb: that's what I refer to
17:56:54 <gouthamr> ahh
17:57:04 <gouthamr> JayF: any examples
17:57:21 <fungi> yeah, if anyone's leaving negative votes or refusing to review changes because they contain a signed-off-by, then we'd need them to know to stop doing that
17:57:25 <JayF> I don't remember specifically, it's not the kind of interaction I'd *want* to remember specifics about tbh
17:57:40 <gmaan> I think company policy is something applicable for both options (new CLA or DCO) so I am nt seeing that as blocker but yes it can impact ongoing development if company need mroe time to decide
17:58:01 <noonedeadpunk> these 2 are different legally
17:58:02 <gouthamr> https://review.opendev.org/q/message:Signed-off-by+project:%5Eopenstack.*
17:58:05 <noonedeadpunk> afaik
17:58:25 <bauzas> I've seen a couple patches already
17:58:30 <fungi> though with the plan jbryce has suggested, if it can be confirmed acceptable, only new contributors would need their employer to review a different icla
17:58:30 <bauzas> with the tag
17:58:39 <gouthamr> (stephenfin obviously)
17:58:39 <fungi> (and only unyil we're ready for the dco switch)
17:58:39 <noonedeadpunk> so if the policy is - what is not explicitly allowed is prohibited - you will get blocked
17:58:55 <noonedeadpunk> yes, right
17:59:13 <noonedeadpunk> it might be best option tbh
17:59:35 <bauzas> that would be *the less worst*
17:59:36 <noonedeadpunk> we jsut don't know if it's possible, so need to prepare to the worst one
17:59:41 <gouthamr> time check
18:00:09 <gouthamr> good discussion so far, and i think we have enough data to take next steps here, and an AI to dig further
18:00:13 <gmaan> blocked you mean especially from company policy checks/time they need?
18:00:49 <gmaan> bcz from developer action to correct the commit is easy one
18:01:28 <bauzas> that would certainly need some proper onboarding period
18:01:34 <bauzas> even for devs
18:01:35 <gouthamr> alright, we're a bit over.. and we had several other agenda items we didn't cover.. I don't want to stop discussing this particular topic because it is an important one
18:01:44 <gmaan> do not want to say on behalf of org as each org has different process but it is unlikely that org will say NO to DCO
18:01:47 <gouthamr> so please don't let meetbot's messages interrupt you
18:01:52 <gouthamr> thank you all for attending today's meeting
18:02:06 <gouthamr> #endmeeting