| gmann | spotz: do you know if RDO build for OpenStack yoga is ready ? I did not see any blog or announcement here https://blogs.rdoproject.org/ | 00:25 |
|---|---|---|
| fungi | we started mirroring the packages from it a week or so ago | 00:27 |
| fungi | at least i think that's what https://static.opendev.org/mirror/centos/8-stream/cloud/x86_64/openstack-yoga/ is | 00:35 |
| spotz | gmann we'll be announcing the release tomorrow or Wednesday so yes | 00:49 |
| spotz | as fungi said it was ready late last week but it didn't make sense to announce on a Friday | 00:50 |
| gmann | ok, thanks | 00:51 |
| spotz | Not sure if the docs change has merged I'll double check | 00:55 |
| spotz | Yeah docs aren't merged yet but if you need them https://review.rdoproject.org/r/c/rdo-website/+/42138 | 00:56 |
| gmann | thanks, that works fine | 01:14 |
| opendevreview | Kendall Nelson proposed openstack/governance master: Defining Tech Preview https://review.opendev.org/c/openstack/governance/+/834208 | 05:24 |
| *** pojadhav- is now known as pojadhav|pto | 06:20 | |
| opendevreview | Hervé Beraud proposed openstack/governance master: Remove oslo's TaCT SIG liaisons https://review.opendev.org/c/openstack/governance/+/839317 | 08:22 |
| opendevreview | Hervé Beraud proposed openstack/governance master: Remove oslo's TaCT SIG liaisons https://review.opendev.org/c/openstack/governance/+/839317 | 08:44 |
| rosmaita | this is kind of low-priority, and i don't know who to ask, but is the Owner on this patch OK? https://review.opendev.org/c/openstack/cinder/+/836996 | 12:07 |
| rosmaita | Also, does CLA checking happen when the review is submitted, or before the patch is merged?) | 12:07 |
| fungi | when they try to push a change to a project which has cla enforcement, gerrit checks whether the account pushing the change has agreed to the icla and returns an error refusing the push if not | 12:13 |
| fungi | "DataCore Software Uploaded patch set 1." | 12:14 |
| fungi | looks like they used their third-party ci account to push that change for review | 12:16 |
| fungi | whoever maintains that account probably agreed to the icla for it | 12:16 |
| rosmaita | fungi: thanks ... is it ok if a rotating cast of characters use that account to submit patches? It seems kind of non-standard | 12:19 |
| fungi | i can't answer that, but i can ask others on the foundation staff. from a gerrit perspective we really have no insight into whether an account gets shared by multiple people | 12:23 |
| fungi | i agree it's not usual, and not how we expect contributors to interact, but as to whether it's legally acceptable i'll see if i can find out from people who are more steeped in that | 12:24 |
| rosmaita | fungi: ok, thanks ... we can enforce it from the project side by -2ing the patch (Sean left a comment on there that it should be submitted from a developer account), but i wasn't clear on the whole thing | 12:25 |
| rosmaita | datacore is on the CLA list: https://openinfra.dev/contributors/corporate | 12:25 |
| rosmaita | i guess it's just a matter of making sure each person posting a patch has signed the icla | 12:26 |
| fungi | gerrit itself doesn't have any differentiation between "developer accounts" and "ci accounts" or whatever, accounts are accounts, so we can't really know anyway | 12:27 |
| fungi | except when someone names the account and associated e-mail address in ways which give clues | 12:27 |
| rosmaita | right | 12:28 |
| fungi | i am not a lawyer, but from what i gather the ccla is actually what the member companies whose counsel is concerned about contributor agreements really care about, the icla is there to plaster over the gaps where someone might be contributing without being covered by a ccla | 12:32 |
| fungi | in 2015 when the board agreed to let openstack "switch to the dco," it was really that they were okay dropping the icla in favor of the dco but wanted stronger ccla enforcement as a stipulation | 12:33 |
| rosmaita | fungi: i was not aware of the dco, guess i didn't pay attention because i signed the icla back in 2011 or something | 12:35 |
| fungi | well, we never switched. i'd still like to though | 12:35 |
| fungi | what they're mostly concerned about is a lawsuit from some company with a large patent portfolio and well-funded legal team, not some rogue independent dev | 12:35 |
| rosmaita | oh, so the foundation said we could, but we never did (switch, i mean) | 12:36 |
| fungi | right | 12:36 |
| rosmaita | IANAL also, but it sounds like from the code review side, we should make sure that whoever is posting the patch has also signed the icla ... though of course, the easiest way to do that is for them to upload the patch themselves using their own gerrit account | 12:40 |
| rosmaita | actually, after this discussion, i am going to just tell them they MUST do that, and they can follow up with the foundation themselves if there is some reason why datacore wants them to submit from the ci account (which i think there is not, using that account was the path of least resistance) | 12:41 |
| rosmaita | fungi: thanks! | 12:41 |
| fungi | right. gerrit checks that the e-mail address of the committer is an address for the account whose credentials are used, and that the account has agreed to the icla | 12:41 |
| rosmaita | works for me | 12:41 |
| rosmaita | a -2 should get their attention | 12:42 |
| fungi | as for the dco sideline, these were the board minutes from the final discussion: https://wiki.openstack.org/wiki/Governance/Foundation/26Oct2015BoardMeetingMinutes | 12:42 |
| rosmaita | cool, ty | 12:42 |
| gmann | fungi: I suspecting if more reply from community member on CFN thread, email rejection and your approval need will be more. that is why I was giving feedback on loosening the number of recipient rule. | 14:29 |
| fungi | yes, it doesn't really increase the work for moderators by leaving it the way it is, but 10 recipients is already a pretty large number. if the suggestion is to increase the limit, then there's probably no point in having a limit and i would just remove that check instead | 14:33 |
| fungi | i see benefit in having the listserv remind people that they're sending messages with far too many recipients and that this is not how mailing lists are intended to be used, but if the openstack tc has some consensus that it's irrelevant i'll remove the check | 14:34 |
| fungi | rosmaita: i talked to jbryce and he agreed there's no legal concern since the company has a signed ccla on file anyway, but that pushing back on the change proposer to make a separate account for themselves distinct from their third-party ci system is still a good idea | 14:54 |
| rosmaita | fungi: thanks! | 14:55 |
| fungi | gmann: i also brought up whether we need to be concerned about imported commits in new deliverables, and the best compromise is probably to make it clear to whoever is proposing the change to add it to governance that by doing so they're effectively vouching for the provenance of any commits from before the icla was enforced on that repo | 14:56 |
| *** pojadhav|pto is now known as pojadhav | 15:03 | |
| *** lbragstad8 is now known as lbragstad | 15:05 | |
| gmann | fungi: on ML restriction, ok but I am sure that is making you to closely monitor that thread and approval the emails in case people reply to thread with no seeing another people reply etc. | 15:53 |
| gmann | fungi: on imported commits, thanks for checking. but I am not clear about what exactly we need to ask author to do? asserting some statement in commit message of governance patch or so? | 15:54 |
| gmann | fungi: rosmaita thanks for discussing the different account things. I think it will be good to add these guidelines in p-t-g as many of us might have same question in future? | 15:55 |
| fungi | gmann: i don't know that we necessarily need to *do* anything, but we might want to remind people in documentation somewhere that by proposing to add a deliverable to openstack/governance they're responsible for the the legality of any commits which are being imported even if they're not the author, same as they would be for any change they pushed as an individual | 16:34 |
| fungi | as long as they're okay assuming that responsibility then there's no concern | 16:35 |
| fungi | but basically the agreement they made to the icla extends to the commits being imported even if those commits aren't theirs, so they should be sure they're comfortable taking legal responsibility for them | 16:36 |
| gmann | fungi: sounds good. let me add that in documentation somewhere. and adding that checklist in commit msg or so can be a formal agreement from them. and can be used if any legal issue we face | 16:36 |
| gmann | fungi: great, is that added in icla ? | 16:37 |
| fungi | there's nothing to add to the icla, i'm just clarifying the meaning of the icla | 16:38 |
| fungi | basically, by proposing a change to import an existing repository into openstack, they're committing those earlier commits to openstack on behalf of their original authors, so the icla applies the same in principle | 16:39 |
| gmann | ok, I think this covers it. the 'contribution ' definition "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Manager for inclusion in,......" in "1. Definitions - https://review.opendev.org/static/cla.html | 16:44 |
| fungi | yes | 16:45 |
| gmann | so we just add an explicit statement in our documentation also by referring to the icla right? | 16:45 |
| fungi | that should be sufficient, i think, yes | 16:46 |
| gmann | ok, thanks I will add that sometime this week. | 16:46 |
| fungi | basically by proposing the import, they take responsibility for those imported commits same as if they were pushing the commits themselves | 16:47 |
| gmann | +1, yeah | 16:48 |
| fungi | and so the icla applies, they're implying they have permission from the copyright owners to push those changes into openstack | 16:49 |
| gmann | dansmith: dmendiza[m]: knikolla: on RBAC meeting on next tuesday. my zoom account have only 45 min meeting limit, if any of you have upgraded account please let me know otherwise I will schedule google meet. | 18:31 |
| dmendiza[m] | Google Meet works for me. | 18:37 |
| clarkb | we also host a jitsi meet with no time limits | 18:42 |
| rosmaita | please no zoom | 18:42 |
| gmann | clarkb: we used that today and it did not work for many attendees | 18:43 |
| clarkb | gmann: ok. we did extensive testing just before the ptg acorss as many brwosers as I have installed locally and with my phoen and it all worked. There is a weird firefox thing which got noted in the ptg documents iirc but maybe we need to put it someplace more prominent if that continues to trip people up | 18:45 |
| clarkb | basically firefox audio autoplay settings affect jitsi meet. WHich means by default on many firefox installs you don't get any audio unless you go an manually enable autoplay for the domain | 18:45 |
| rosmaita | clarkb: ty, that is good to know | 18:46 |
| fungi | firefox also likes to hide the "enable auto-play audio" option somewhere hard to find | 18:47 |
| gmann | not sure what browser they used or phone, it did not work for them in joining issue and audio too. and many of them wanted to be part if discussion but they could not | 18:48 |
| clarkb | gmann: right I'm saying the only known issue on that front is solvable, but does force people to use not firefox or be aware of how to configure firefox unfortunately | 18:49 |
| fungi | which meeting was that? and do you have any details as to what specific problems they experienced? we can't do much to improve the platform if we don't have information on what issues are encountered | 18:49 |
| clarkb | ++ its really hard for us to hear that it never works for anyone else when we do extensive checking before major events like the ptg and debug and do our best to address issues like the firefox thing | 18:50 |
| gmann | RBAC one https://meetpad.opendev.org/secure-rbac | 18:50 |
| gmann | problem they faced, 1. not allowing to join 2. audio issue both some did not hear our voice and for few their audio did not work | 18:51 |
| clarkb | for 2 that sounds exactly like the firefox autoplay issue | 18:51 |
| dansmith | gmann: sorry, I don't have a zoom account, but meet is also good for me | 18:51 |
| fungi | if any of the attendees who had problems can provide more specific information and/or help us troubleshoot, that would be appreciated | 18:51 |
| clarkb | 1. is curious since anyone should be able to join. I suspect that may be due to local firewalls? | 18:51 |
| gmann | dansmith: dmendiza[m]: ok, let me schedule google meet | 18:52 |
| fungi | clarkb: yes, i'm guessing those were corporate firewalls blocking something, but hard to know without details | 18:52 |
| gmann | yeah, I am not sure what firewall or so but if you have any place to give feedback or exact detail about their issue they faced I will be happy to ask them to add there | 18:52 |
| clarkb | we're always happy for people to reach out to us on IRC in #opendev, email us at service-discuss@lists.opendev.org or open a storyboard issue | 18:53 |
| clarkb | that hasn't changed in years... | 18:54 |
| clarkb | I guess the IRC server changed a yaer ago but not the channel name :) | 18:54 |
| gmann | ok, I will inform them next time if someone has problem. | 18:54 |
| gmann | dansmith: dmendiza[m] knikolla scheudle on google meet - https://meet.google.com/gie-derw-eer , updated wiki, send on ML. | 19:00 |
| dansmith | gmann: could we mark the meeting as occurring in -keystone or something so we can merge the patch and get it into the ics file? | 19:55 |
| gmann | dansmith: we had that prevously but issue with that is people are confused with ics file saying meeting on IRC and we do on call. and we forget to ping that call link on IRC. | 20:21 |
| dansmith | ...okay | 20:21 |
| gmann | FYI, Board meeting in 8 min from now https://board.openinfra.dev/meetings/2022-04-26 | 20:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!