17:00:04 <noonedeadpunk> #startmeeting tc
17:00:04 <opendevmeet> Meeting started Tue Jun 10 17:00:04 2025 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:04 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:04 <opendevmeet> The meeting name has been set to 'tc'
17:00:09 <noonedeadpunk> 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:15 <noonedeadpunk> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
17:00:20 <noonedeadpunk> #topic Roll Call
17:00:21 <noonedeadpunk> o/
17:00:43 <gmaan> o/
17:00:48 <noonedeadpunk> noted absence: g o u t h a m r
17:00:56 <gtema> o/
17:02:18 <mnasiadka> o/
17:02:55 <cardoe> o/
17:04:04 <noonedeadpunk> courtesy-ping: frickler spotz[m] bauzas
17:04:12 <bauzas> o/
17:05:35 <noonedeadpunk> #topic Last Week's AIs
17:06:02 <noonedeadpunk> I think the bigest AI on our plate as of today is switch to DCO
17:06:17 <fungi> i'm at your disposal for greasing that wheel
17:06:41 <noonedeadpunk> I saw a lot of patches being prepared for infra side of things
17:06:54 <noonedeadpunk> #link https://review.opendev.org/q/hashtag:%22dco-signed-off-by%22+(status:open%20OR%20status:merged)
17:07:14 <fungi> i hope everything we can think of is covered now, but if anyone catches something else let me know or propose a patch yourself
17:07:29 <noonedeadpunk> #link https://review.opendev.org/q/hashtag:dco-signed-off-by
17:07:39 <fungi> also expect we'll miss some stuff we need to fix later, not the end of the world
17:08:39 <fungi> and for people with approval rights on various repos, changes to add a signed-off-by/git commit -s should be safe to merge well in advance
17:09:00 <spotz[m]> o/
17:09:30 <fungi> gerrit already allows that in commit messages, it's just that we'll start requiring it at the end of the month
17:11:06 <noonedeadpunk> yes, right
17:11:29 <noonedeadpunk> also 2 things I was aware of in tooling seems to be patched (or well, patches were proposed0
17:11:46 <noonedeadpunk> so I don't have anything to add from top of my head at least
17:12:14 <mnasiadka> I think jrosser raised that question, do we know how to treat signed-off-by in multi-contributor (co-authored-by) patches?
17:13:03 <gmaan> I am also checking how co-author is done but could not find any concrete evidence from official DCO side
17:13:04 <fungi> that can be a matter for tc policy, but it won't impact gerrit/automtion
17:13:52 <fungi> co-authored-by was only ever a suggestion. if the tc wants to treat additional unneeded signed-off-by as equivalent they can say that somewhere
17:14:16 <noonedeadpunk> From other side I personally very conserned about amount of potential blind spots in policies we might have right now, which can also negatively influence contributors (in terms of matching their internal rules and allowances)
17:14:31 <jrosser> I am concerned that my legal advisor will go over all this with a microscope and any inconsistency or ambiguity may turn into a blocker for me continuing to contribute
17:14:41 <fungi> noonedeadpunk: do you have ay examples?
17:15:03 <jrosser> so the co-authored-by with no explanation seems a big red flag for me now
17:15:06 <noonedeadpunk> well the example is above
17:15:21 <fungi> jrosser: definitely make sure your legal advisor knows this documentation was composed by community volunteers and not other lawyers
17:15:30 <gmaan> I am reading this and it seems both way is ok
17:15:31 <gmaan> #link https://www.chef.io/amp/introducing-developer-certificate-of-origin/djUrUUdsTysxMW1TVzcxbDdaWGd0N3NUWVdRPQ2
17:15:43 <clarkb> I think it is common for everyone who touches the code to sign off on the commit. This would effectively make co authored by redundant?
17:16:14 <noonedeadpunk> "Subsequent developers who co-author or otherwise help shepherd the contribution in some way also add their own attestation"
17:16:32 <noonedeadpunk> so eventually, regardless of co-authored, sign off is expected I assume?
17:16:40 <fungi> in theory co-authored-by could be used to record additional authors, while not all authors may have added a signed-off-by (just the committers), and not all committers are also authors, so the two sets could be considered disjoint
17:16:44 <mnasiadka> expected by not required?
17:16:51 <mnasiadka> s/by/but/
17:17:24 <noonedeadpunk> I'd guess that everyone who touches code require to sign-off actually
17:17:26 <gmaan> ++ what fungi mentioned ^^
17:17:28 <clarkb> Gerrit enforcement only requires a single sign off from one of the author/committer/person pushing the code
17:17:34 <mnasiadka> I think we need some guidance in the contributor-guide
17:17:44 <noonedeadpunk> only except case when yopu're using some-one else code without any changes but with explicit allowance
17:17:56 <fungi> consider the case of a patch submitted as a bug attachment where the author said in a bug comment that they were fine with the terms of the dco and so the person pushing that patch into gerrit (the committer) adds their own signed-off-by
17:17:57 <noonedeadpunk> Gerrit - yes, but not legal
17:18:00 <spotz[m]> We can add that in easy enough as long as I patch the right thing:)
17:18:23 <noonedeadpunk> and we are all talking about quite legal things here without being lawyers, which is concerning
17:18:28 <jrosser> I would just like the documentation to be unambiguous
17:18:48 <jrosser> putting something uncertain i to the example commit message cannot be a good starting point
17:19:00 <noonedeadpunk> fungi: yeah, this falls right under exception I mentioned :)
17:19:49 <gmaan> but DCO does not say about co-author things so its up to us to define the guidelines.
17:20:01 <fungi> the terms of the dco seem pretty clear, but obviously any of us concerned with legal implications should be consulting their personal/employer's legal counsel. the foundation has already conulted their own legal counsel who agreed that this was fine
17:20:33 <noonedeadpunk> I think it was general guidance which is fine?
17:20:40 <noonedeadpunk> unless we missuse it badly?
17:21:10 <fungi> law is generally about intent and not technical deyai
17:21:11 <gmaan> yeah, we do not need to check with legal things for this
17:21:12 <fungi> detai
17:21:14 <noonedeadpunk> as using someone's modified code without sign-off of that person can be violation?
17:21:14 <fungi> ls
17:21:23 <fungi> wow, this enter key is very poorly placed
17:22:16 <fungi> i would not say that "we" don't need to consult lawyers. the foundation has consulted their lawyers, and anyone who is concerned about the current plan should consult their own (or their employer's) lawyers
17:22:33 <noonedeadpunk> Yeah, could be. Just law system to which I used is all about technicalities and nobody ever cares about intent...
17:22:53 <noonedeadpunk> Which is very different from US, so that's I guess I feel more concenred
17:23:40 <fungi> i constantly hear the reverse, that software developers assume the law is like a deterministic computer algorithm, when it's quite the opposite and rather focused on what people are likely to assume or believe or intend
17:23:58 <noonedeadpunk> so what you are saying, that just gerrit coverage is enough for us and if commit was allowed to checks - we don't need any more awareness about the daily review process?
17:24:10 <gmaan> let's add 'each author/co-author need sign-off and additionally they can add co-author to indicate they are co-author" ?
17:24:31 <noonedeadpunk> fungi: it really like a deterministic computer algorithm from where I am
17:24:47 <fungi> proving "best effort" is typically sufficient, from what i've seen, but again i'm no lawyer so you should consult one you trust
17:24:50 <noonedeadpunk> gmaan: sounds good to me
17:25:42 <mnasiadka> Is Gerrit checking if there's any signed off by - or is it matching the author/committer email?
17:25:52 <noonedeadpunk> it is, yes
17:26:19 <noonedeadpunk> there's a logic to match if either author or commiter are in dco
17:26:21 <fungi> it checks that at least the committer or author has added a signed-off-by (at least one of the two)
17:26:26 <noonedeadpunk> but only 1 match is enough to pass
17:26:49 <mnasiadka> well then can we require something that is not enforced? ;-)
17:27:03 <spotz[m]> You can highly recommend:)
17:27:25 <gmaan> yeah, recommended so that we have consistence way for everyone
17:27:28 <mnasiadka> So let's highly recommend :)
17:27:42 <fungi> typically they're the same person. if they're not and only the author has added a signed-off-by then you can assume the committer is implying they made no concrete changes. if only the committer and not the author has added a signed-off-by then the implication is that they checked with the author that the change meets the necessary terms
17:28:28 <spotz[m]> My corner case which matches this is generally grammar changes. Valuable but still supporting the original
17:28:50 <fungi> it would be ideal though for the tc to publish a document stating clearly what the openstack project assumes a signed-off-by in a commit message indicates, and that document can cover corner cases if it's deemed useful
17:29:32 <noonedeadpunk> I'd say that this one is really a good start: https://review.opendev.org/c/openstack/contributor-guide/+/950839
17:30:19 <fungi> #
17:30:22 <fungi> gah
17:30:29 <fungi> #link https://wiki.openstack.org/wiki/OpenStackAndItsCLA#The_Developer_Certificate_of_Origin covers some of this
17:30:58 <fungi> written a decade ago by your predecessors
17:31:07 <noonedeadpunk> I think we also might want to add recommendation for core reviewers to ensure that there was no significant part of code sumbitted by 3rd partiies without DCO
17:31:20 <noonedeadpunk> heh
17:31:43 <fungi> remember that the same could in theory have happened under the cla too
17:32:02 <noonedeadpunk> not really?
17:32:14 <fungi> and reviewers weren't typically too stressed about someone pushing changes written by others
17:32:29 <noonedeadpunk> yes, but to push smth each need to sign CLA?
17:32:46 <noonedeadpunk> otherwise gferrit won't allow you to update someone elses patch
17:32:47 <fungi> and now to push something each will need to add a dco signed-off-by
17:33:17 <noonedeadpunk> but this will not really be enforced, as if author has DCO it's enough for all committers to skip it
17:33:24 <fungi> any opportunity to maliciously contravene either the cla or dco is similarly easy
17:34:21 <noonedeadpunk> I'm just looking at a patch https://review.opendev.org/c/openstack/octavia/+/558962 right now as some example of very collaborative effort through years (unsuccessfull though)
17:34:30 <noonedeadpunk> anyway, I think it's time to move on
17:34:37 <fungi> in fact, it's perhaps an even stronger protection because the committer only needed to agree to the icla once, while they need to attest to the dco with every commit they push to gerrit
17:35:20 <noonedeadpunk> #topic Improving Contributor experience
17:35:25 <mnasiadka> anyway, maybe we're stressing too much about it - and we just need to document that it's highly recommended that all authors (according to a) field in DCO) should do the sign off
17:36:14 <noonedeadpunk> let's continue to discuss https://review.opendev.org/c/openstack/contributor-guide/+/950839 asynchronously for that
17:36:44 <gmaan> mnasiadka ++
17:37:19 <noonedeadpunk> So improving experience.
17:37:28 <noonedeadpunk> #link https://etherpad.opendev.org/p/apr2025-ptg-os-tc
17:37:52 <noonedeadpunk> this was topic from the PTG which we seems to be still tracking
17:39:01 <fungi> from the foundation community manager side of things, i'll note that we're in the process of doing per-team maintainer and contributor survey analysis and getting ready to do team-specific outreach to talk about more focused results
17:39:22 <noonedeadpunk> that sounds really great
17:39:47 <fungi> for now we're prioritizing teams who had multiple maintainer and contribiutor responses
17:39:54 <noonedeadpunk> and totally in line with our intent to improve communication with contributors which was suggested on previous meetings
17:40:27 <fungi> but also, if anyone wants to fill out the maintainer and contributor surveys for the epoxy cycle they can do so and we'll revisit the additional responses when possible
17:40:43 <noonedeadpunk> also there was a good suggestion on asking teams to review their contributrors guide regarding communication channels and how to reach teams out
17:40:46 <fungi> as well as planning to do a similar round after the flamingo cycle has wrapped up
17:42:13 <noonedeadpunk> sounds good thanks!
17:43:14 <noonedeadpunk> #topic A check on gate health
17:43:34 <noonedeadpunk> Anyone want to share on the topic?
17:44:07 <noonedeadpunk> I have seen just couple issues with Debian/Ubuntu mirrors last week, but infra team was on top of things as always
17:44:07 <fungi> i don't recall any major disruption from the infrastructure side in the past week
17:44:25 <fungi> yeah, there was an ubuntu mirror problem last week for a day or so
17:44:25 <noonedeadpunk> (or maybe it was 1 week ago)
17:44:45 <fungi> not a problem with our ubuntu mirrors, just the upstream ones
17:45:02 <noonedeadpunk> there was smth with our mirrors as well for one of providers...
17:45:10 <fungi> any jobs relying exclusively on the opendev mirrors would have been shielded from that issue
17:45:14 <noonedeadpunk> I can't already recall which one, but it was a specific one
17:45:47 <noonedeadpunk> it was solved within half a day as well from what I spotted
17:45:52 <fungi> doesn't sound familiar, but i might have missed it
17:47:47 <noonedeadpunk> ok, so seems it all pretty much stable then
17:48:05 <noonedeadpunk> #topic TC Tracker
17:48:12 <noonedeadpunk> #link https://etherpad.opendev.org/p/tc-2025.2-tracker
17:49:26 <noonedeadpunk> does anybody have any updates on the topic to discuss?
17:50:11 <noonedeadpunk> Contributor/Maintainer survey was already touched a little bit as part of the previous topic
17:51:15 <noonedeadpunk> Eventlet removal seems actively in progress and projects working towards the goal
17:51:49 <noonedeadpunk> Not sure about the completion rate or where we are exactly on the global scale though
17:53:06 <noonedeadpunk> #topic Open Discussion and Reviews
17:53:07 <fungi> yeah, i don't see anyone in here at the moment who i expect would provide an update on eventlet removal
17:53:23 <gmaan> I would like to highlight cyborg project state and its gate status
17:53:32 <gmaan> you might have seen email from sean
17:53:34 <gmaan> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/IBW4TXON64U44TTRLKXQR24BPFDTZA2V/
17:53:53 <gmaan> this CI fix not yet merged #link https://review.opendev.org/c/openstack/cyborg/+/949772
17:54:16 * noonedeadpunk have issues with ML loading
17:54:18 <gmaan> last changes merged in cyborg was ~2 month ago
17:54:21 <gmaan> #link https://review.opendev.org/q/project:openstack/cyborg
17:54:53 <gmaan> I think we need to discuss about it so that we can provide accurate status of this project to release team before deadline
17:54:56 <fungi> "issues" like the list archive page isn't coming up?
17:55:13 <noonedeadpunk> and the deadline is M-2, right?
17:55:16 <fungi> (it popped immediately for me)
17:55:46 <gmaan> yeah, m-3. around end of month
17:55:49 <gmaan> sorry m-2
17:55:58 <noonedeadpunk> ok, so there was no reply to the ML either
17:56:05 <noonedeadpunk> yeah, it's not great to say the least.
17:56:15 <gmaan> July 3rd #link https://releases.openstack.org/flamingo/schedule.html#f-2
17:56:29 <fungi> yeah, no reply on-list at the very least
17:56:41 <noonedeadpunk> I also want to self-report about the Vitrage, as I failed to get the project enough love this cycle, so tempest is failing there at the moment.
17:56:45 <gmaan> I will add it in next week meeting agenda and till then no response from project, at least we can disucss about next action
17:57:01 <noonedeadpunk> Hopefully, I will take time during PTO at what is the root cause there
17:57:14 <fungi> in the past the cyborg team tended to only respond over wechat/weixin
17:57:35 <gmaan> at least they use to merge the changes even they are no active on ML, IRC etc
17:57:46 <gmaan> but it seems no activity on gerrit also
17:58:05 <fungi> i've sometimes leaned on horace (foundation's china community manager) to reach out to the cyborg maintainers, and can ask him if needed
17:58:46 <gmaan> I am not sure we should make that a practice and bother foundation staff for asking project core to merge the things or being active
17:58:54 <noonedeadpunk> fungi: that would be pretty much appreciated if possible
17:59:21 <gmaan> it should be coming from project maintainer itself as self-motivation or self-responsibility at lease for PTL
17:59:21 <noonedeadpunk> but also I think we are having some rules on communication channels here
17:59:50 <fungi> get up with me after the meeting and we can work on specific outreach messaging, but i agree part of the message should be about monitoring standard project discussion channels
17:59:53 <gmaan> I do not think communication is issue here. project cores are not active. It is not like they are missing things bcz of communciation
18:00:46 <fungi> and, yes, we should be asking them whether the project is defunct or in search of new leadership
18:00:51 <noonedeadpunk> well, absernt maintainers are not _that_concerning, given that a limited amount of patches are theres
18:01:07 <noonedeadpunk> and besides broken CI - we won't be _that_ bothered usually
18:02:02 <noonedeadpunk> but I think it still might be useful to reach through known to work channels for some insight if it's an accident or there's really nobody behind the project anymore
18:02:13 <noonedeadpunk> ok, thanks for raising that gmaan!
18:02:19 <noonedeadpunk> and we're out of time
18:02:23 <noonedeadpunk> #endmeeting