| *** ralonsoh_out is now known as ralonsoh | 05:25 | |
| *** jroll04 is now known as jroll0 | 07:17 | |
| opendevreview | Guillaume Boutry proposed openstack/openstack-manuals master: Add ubuntu installation details for 2024.1,.2,2025.1 https://review.opendev.org/c/openstack/openstack-manuals/+/950532 | 12:02 |
|---|---|---|
| fungi | sean-k-mooney brought up a great point on the dco thread i hadn't considered... any of our patch generation jobs need to add a signed-off-by to their commits | 13:48 |
| fungi | that's probably also a great time to add generated-by footers too | 13:49 |
| frickler | more work, yay /s | 13:54 |
| mnasiadka | who doesn't like more work... :) | 14:20 |
| clarkb | fungi: sean-k-mooney: but also I'm not sure any existing patches would need to be updated | 14:50 |
| clarkb | we're enforcing the checks at push time. If you're clear when you push I don't know why we'd need a busy work pass to repush everything under the new rules | 14:51 |
| gmaan | yeah, that is the main point, we do not need to change the exiting patches, if new commit in that patch then we need otherwise old one stay same and valid as per old CLA | 14:52 |
| gmaan | if we have to change every existing chnage then it is lot of work | 14:52 |
| gmaan | especially when they have one +2 and change in commit msg reset the vote | 14:53 |
| fungi | right, changes/revisions pushed before the switch were accepted under the old requirements which were valid at that time | 14:53 |
| fungi | there is no need to revise history | 14:53 |
| clarkb | with the bots we put them in a fake CLA group iirc. I don't think there is somethign similar for not needing signed off by unfortunately. However, there are probably like 4 or 5 places in code that need to add a -s to one command so not a big deal hopefully | 14:54 |
| fungi | right, and like i said, we're overdue to fix those scripts so they include generated-by footers anyway, all the same scripts/jobs will need both really | 14:56 |
| jbryce | thanks for all the feedback on dco. i was able to get some initial guidance from legal on timing, and it sounds like we can push past june 1 in our current configuration without changes if we come up with a plan to switch to a dco model sooner than later. what would be the fastest reasonable timeframe to make the switch? i think waiting until october (2025.2 release) would be pushing the limits | 16:01 |
| jbryce | if it's going to take a longer time, then we'll probably need to implement a new CLA process for the new entity | 16:01 |
| clarkb | on the technical side I feel like we could get it done today/tomorrow :) the biggest hurdles are going to be the people side | 16:02 |
| clarkb | Maybe we set some time frame like 30 days (so June 30th ish?) | 16:02 |
| JayF | As much as I was the person pushing for "not 10 days", I almost think waiting until a release-border is too long, because it'd keep it outta mind | 16:02 |
| fungi | tc-members: ^ | 16:02 |
| JayF | if we can just say 30 days from when the resolution lands, that seems ideal -- a formal announcement, with a deadline for downstream contribution orgs to meet | 16:03 |
| gmaan | IMO, either we should it asap before m-2 (https://releases.openstack.org/flamingo/schedule.html#f-2) or push it after release. doing it during release time is not good timing | 16:05 |
| bauzas | 30 days seems a reasonable period for our employers to get clearance on the DCO | 16:05 |
| gouthamr | M-2 sounds reasonable to me | 16:05 |
| jbryce | they also said it's ok to start implement a check requiring dco sign off on commits while leaving the cla in place, but i'm not sure that fixes either of the problems raised (1. educating folks about the technical implementation to sign off 2. giving companies time if they need to review and clear DCO for contribution authorization) | 16:05 |
| gouthamr | i really don't want to use M-3 or FF because we could break the release | 16:05 |
| gouthamr | by preventing patches even if things seem simple | 16:05 |
| gmaan | yeah, let's push for m-2 but resolution we should merge before June start | 16:05 |
| JayF | it's very nice when the timelines align like that \o/ it also has the side effect of me being smack in the middle of my sabbatical when it rolls out, so SGTM lol | 16:06 |
| gmaan | true | 16:06 |
| clarkb | https://releases.openstack.org/flamingo/schedule.html is the release schedule. M-2 is the week ending July 4 | 16:07 |
| gmaan | yeah | 16:07 |
| gouthamr | July 3, 2025 is the Flamingo-2 milestone | 16:07 |
| gmaan | I think we should switch in one shot instead of supporting both that can create confusion and maybe more work as we might be more lazy to finish it | 16:07 |
| jbryce | so would june 30 as the final CLA contribution date work (m-2 is july 3)? i will need to go back and get confirmation on this plan | 16:07 |
| jbryce | gmaan: that was my gut too | 16:07 |
| bauzas | what's cool is that people can start signing-off their patches | 16:08 |
| bauzas | we won't enforce that until July 3 | 16:08 |
| gmaan | june 30th is ok as more visible timeline. and we will have time (9 days from now) to merge resolution and then 30 days to implement | 16:08 |
| JayF | jbryce: I think TC will also need final confirmation of the timeline as well; we don't want a small consensus of a couple of TC members and a loud former one to win by timezone fiat :D | 16:08 |
| noonedeadpunk | isn't M-2 in like... 2 weeks? | 16:08 |
| clarkb | noonedeadpunk: no see the link above its 1.5 months ish | 16:09 |
| noonedeadpunk | so 15 days instead of 10? | 16:09 |
| jbryce | m-2 is july 3 | 16:09 |
| fungi | convenient indeed, i too am planning to be on vacation the week before/after july 4 | 16:09 |
| gmaan | noonedeadpunk: no, https://releases.openstack.org/flamingo/schedule.html#f-2 | 16:09 |
| gmaan | gouthamr: if you can update the timeline in your resolution then we can see the reaction this week | 16:09 |
| noonedeadpunk | oh, I mixed June with July | 16:09 |
| noonedeadpunk | eh | 16:09 |
| noonedeadpunk | yeah, M-2 sounds reasonable then | 16:10 |
| noonedeadpunk | if it makes any difference though | 16:10 |
| gmaan | JayF: yeah, let's put this in resolution and along with all TC, community members can also vote/feedback | 16:10 |
| JayF | I guess I should say for this audience if I haven't? Probably should email list about it beforehand, I guess; but I'm gone the entire last half of June and all of July on a sabbatical | 16:10 |
| gouthamr | gmaan: ack | 16:10 |
| gmaan | jbryce: do you need final resolution with timeline merged to consider it a timeline to convey or seeing positive response on resolution can work also | 16:11 |
| jbryce | here is a specific proposal here that i will go get initial additional feedback from legal on (and can update gerrit as well once i get that). final date for CLA contributions of june 30 with DCO enforcement starting at 2025-07-01 00:00UTC | 16:11 |
| gmaan | we need 7 days wait to merge the resolution if all positive feedback | 16:11 |
| noonedeadpunk | that sounds more then reasonable | 16:11 |
| noonedeadpunk | we have exactly 1m after merge | 16:12 |
| jbryce | gmaan: i just wanted to gut check some timing here with folks to keep my conversation with legal going. i think this will be ok, but don't want to propose it as official in gerrit until i get sign off from them | 16:12 |
| gmaan | ++ on doing it in parallel. | 16:12 |
| JayF | this sounds pretty much like an ideal solution from my POV, thank you jbryce | 16:14 |
| jbryce | ok thanks for the quick feedback. i'll do another round of legal checks and let you know what i hear. i put a quick update into the resolution in gerrit as well | 16:17 |
| -opendevstatus- NOTICE: Gerrit is being updated to the latest 3.10 bugfix release as part of early prep work for an eventual 3.11 upgrade. Gerrit will be offline momentarily while it restarts on the new version. | 17:35 | |
| * gouthamr gets out of meetings and looks at this properly | 18:00 | |
| gouthamr | jbryce: i know you didn't want to propose the dates officially on gerrit prior to legal sign off.. but, since the proposal currently states June 1st; and that's quite infeasible, i'll update the resolution either way to capture this and other feedback. | 18:01 |
| gouthamr | 18:01 | |
| gouthamr | For sure i'll look for your confirmation/follow up on this to update it again if necessary | 18:01 |
| gouthamr | fungi: clarkb: sorry if you already clarified... but, to update the resolution i need to ask: do you know if proposing patches through the UI will be prevented if "signed-off-by" is not included manually? | 18:20 |
| gouthamr | changes made through the UI include: rebases through the "Rebase" button, edits, cherry-picks | 18:21 |
| fungi | i don't know, but this is something that could be tested by changing the acl on e.g. a sandbox repo or holding a gerrit deploy job | 18:22 |
| clarkb | gouthamr: I'm not 100% certain but my suspicion based on what I saw when looking up the error message yesterday is that you'll be able to edit changes that already have the signed off by on them for yourself | 18:23 |
| clarkb | but if that isn't already present the you would not be able to | 18:23 |
| fungi | though you could still use the webui to edit the commit message and add it | 18:23 |
| gouthamr | yes you could | 18:23 |
| gouthamr | the cherry-pick interface allows you to edit the commit message | 18:25 |
| gouthamr | rebase does not | 18:25 |
| fungi | but you could do it in two steps if needed | 18:25 |
| clarkb | its possible rebase isn't considered enough of a new change to trigger those checks either | 18:26 |
| clarkb | since you're taking an existing commit as is and moving it to another parent (local rebase allows you to do edits but gerrit doesn't iirc) | 18:26 |
| gouthamr | yes it doesn't | 18:26 |
| fungi | but regardless would need testing to find out for sure | 18:26 |
| gouthamr | ack, can you please help with this determination :) i can update the resolution based on what you find out.. but folks are asking for clarity :D | 18:27 |
| gouthamr | I can flag this as a TBD alongside whatever the legal team will tell us about the enforcement date.. | 18:28 |
| clarkb | I think we should document this but the resolution serves a different purpose | 18:28 |
| clarkb | I'm not sure we need to conflate the two together | 18:28 |
| gouthamr | i am with you there | 18:28 |
| fungi | yes, the resolution doesn't seem like the place to put user instructions | 18:28 |
| gouthamr | where else would we put in the details regarding the compliance though? | 18:28 |
| gouthamr | its short term | 18:29 |
| fungi | ongoing dco compliance information should be in a more long-lived document (contributor guide, project teams guide, legal faq in governance...) | 18:29 |
| gouthamr | at some point, existing patches will all merge without the DCO stuff, because they existed.. or they'll get updated locally.. a small percentage of these would get updated via the web-ui | 18:30 |
| clarkb | or the web ui won't work for that and you'll haev to use git locally. Not a big deal | 18:30 |
| gouthamr | yeah, but can you skirt compliance through this? | 18:31 |
| fungi | i would not expect that, as google (who uses gerrit and employs most of the maintainers) seem to be pretty particular about such things | 18:31 |
| clarkb | fungi: an easy way to test would be to update sandbox to require the dco today | 18:32 |
| clarkb | that might be a good first step | 18:32 |
| fungi | yes, that was my first suggestion | 18:32 |
| clarkb | oh ya I see that now. I think we can go ahead and do that | 18:33 |
| fungi | i'm looking to see which sandbox we would want to do that on | 18:33 |
| gouthamr | many thanks, let me know | 18:33 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: [resolution] Replace CLA with DCO for all contributions https://review.opendev.org/c/openstack/governance/+/950463 | 18:33 |
| fungi | we don't have any openstack-specific sandboxes but could do it on opendev/sandbox temporarily i guess | 18:34 |
| clarkb | yes I think that is fine. The sandbox is there to test user interaction and this falls under that | 18:34 |
| fungi | remote: https://review.opendev.org/c/openstack/project-config/+/950596 Temporarily require Signed-Off-By in the sandbox [NEW] | 18:38 |
| fungi | mmm, just dawned on me we may need to add that directive to the allowlist in our acl linter too | 18:39 |
| clarkb | fungi: gouthamr: I have a held gerrit 3.11 for upgrade testing at https://104.130.253.194 I updated x/test-project to require signed off by and tried to edit a file in there and it failed to submit the edit | 18:41 |
| clarkb | curiously I don't see a reabse button as I was going to test that next | 18:42 |
| fungi | you may need to merge another change to the repo first | 18:42 |
| fungi | i think the rebase button is hidden if the parent is the branch tip and so fast-forwardable already | 18:42 |
| clarkb | makes sense. Your changes lgtm and are probably sufficient for furhter testing. I'll note you don't get a clear error message just a failure to submit the edit in the web ui. I'm going to try and track down a server side error message next | 18:43 |
| fungi | i'm also curious to see how the error presents via git-review | 18:44 |
| clarkb | aha: the first attempt I hit save and publish from the file view. If i save the file then try to publish edit from the top level change page I get Could not perform action: not Signed-off-by author/committer/uploader in message footer | 18:45 |
| clarkb | fungi: ^ that message looks very much like the one I found in the source code so expect git-review to report similar | 18:46 |
| clarkb | that did not generate a message in the error_log so not sure if it recorded server side anywhere | 18:46 |
| fungi | that's surprisingly clear | 18:47 |
| clarkb | attempting to cherry pick change 5 onto master produces the same result | 18:47 |
| fungi | the corner case of save and publish from the file view seems worth reporting upstream as a cosmetic bug | 18:47 |
| clarkb | "Could not perform action: not Signed-off-by author/committer/uploader in message footer" | 18:48 |
| clarkb | fungi: ya I should try more testing of that just to be sure it wasn't pebkac but I agree | 18:48 |
| clarkb | but I think edit and cherry-pick are covered. Not sure about rebase. But also I think rebase is less important as you aren't making substantive changes via rebase in the web ui | 18:49 |
| clarkb | but also that is 3.11 not 3.10 so worht updating sandbox and doing more direct testing of reality | 18:49 |
| fungi | yeah, once my project-config changes deploy everyone should feel free to test these things with the openstack/sandbox repo to their hearts' content | 18:50 |
| gouthamr | that's awesome!! | 19:03 |
| gouthamr | thank you for checking this clarkb! | 19:04 |
| gouthamr | will the 3.11 upgrade happen by our enforcement date though? | 19:04 |
| gouthamr | fungi: ty and +1 on the sandbox change.. can you please merge it and flag it to the ML? think project maintainers could find this experimentation useful | 19:49 |
| gouthamr | https://www.oftc.net/2025/04/25/update/ | 19:49 |
| gouthamr | ^ good news on the Matrix OFTC bridge.. i noticed a month late :) | 19:49 |
| gouthamr | but, the app-service user for OFTC is still gone | 19:49 |
| gouthamr | can't find any info on where/why that happened.. | 19:50 |
| gouthamr | but, big deal :D you can continue to talk to OFTC users and join channels thanks to the bridge | 19:50 |
| clarkb | gouthamr: I'm hoping to upgrade to 3.11 in early to mid june so maybe. A lot of that is still in the air as I'm just now bootstrapping the more in depth testing | 19:58 |
| gouthamr | ah ack clarkb .. makes sense, just wondered if any of this DCO stuff is different in it.. | 20:02 |
| gouthamr | don't see anything around it in https://www.gerritcodereview.com/3.11.html | 20:02 |
| gouthamr | https://gerrit-review.googlesource.com/421177 :/ | 20:02 |
| fungi | probably not, the feature has been there for many years and i don't expect it's something that sees much churn, basically feature-complete | 20:03 |
| gouthamr | ++ | 20:10 |
| gouthamr | unrelated to DCO, but i think we should continue allowing anyone to propose reverts through explicit overrides: https://gerrit-review.googlesource.com/421177 | 20:11 |
| fungi | we still allow registered users to propose changes too, so i don't see why restricting reverts specifically would thwart spammers | 20:13 |
| fungi | granted, i do reverts via git push anyway because i want to be able to provide more context in my commit messages | 20:14 |
| gouthamr | +1 the commit message called this out as a problem for the base gerrit repo itself ... but i think its valuable to let any registered user revert via the UI | 20:15 |
| gouthamr | you can still edit the commit message and provide reasoning | 20:15 |
| gouthamr | s/valuable/valuable for OpenStack projects | 20:15 |
| clarkb | so those edits are in initDefaultAclsForRegisteredUsers. I think that runs when there are no preexisting acls | 20:18 |
| gouthamr | oh | 20:18 |
| clarkb | basically when you create a new gerrit installation. I don't think that will affect us since our installation has acls | 20:18 |
| gouthamr | ah great! | 20:19 |
| clarkb | and yes that change was merged in 2024 | 20:19 |
| clarkb | we should be running with that included already | 20:19 |
| gouthamr | but it claimed to be new in 3.11 | 20:19 |
| gouthamr | sorry for the panic :) | 20:20 |
| clarkb | hrm maybe it merged immediately after the 3.10 release | 20:20 |
| clarkb | 3.11 was released in november and 3.12 was just realsed in may (I thought 3.10 was may too) | 20:21 |
| clarkb | could be they split their stable-3.10 branch before the release so master was effectively 3.11. But in any case I don't think that affects us as we aren't creating a new install | 20:21 |
| clarkb | fungi: re spam I think a lot of the spam operations are using web apis or bots using tools like selenium and not using git protocols | 20:22 |
| fungi | yeah but we allow registered users to create new changes through the webui too don't we? | 20:23 |
| clarkb | I don't think so | 20:23 |
| fungi | or has that feature not reached completion yet? | 20:23 |
| clarkb | you can modify changes | 20:23 |
| clarkb | but not create new ones iirc | 20:23 |
| clarkb | (unless you revert apparently) | 20:23 |
| gouthamr | oh, i thought i tried this recently | 20:23 |
| clarkb | there is no make a new change button | 20:24 |
| gouthamr | when did it disappear :O | 20:24 |
| fungi | https://review.opendev.org/admin/repos/openstack/governance,commands | 20:24 |
| fungi | "create change" | 20:24 |
| gouthamr | yes! | 20:24 |
| clarkb | huh TIL | 20:25 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Hello spam https://review.opendev.org/c/openstack/governance/+/950602 | 20:25 |
| gouthamr | :P i use this to test CI occasionally | 20:25 |
| fungi | it's not a page users tend to end up at unless they know it has that button, i expect | 20:25 |
| clarkb | I guess by hiding that under repo administrivia the spammer haven't found it. Its also possible that gerrit's google gerrit disables that specifically too | 20:25 |
| clarkb | I'm the type of user that hates using gerrit for this stuff because its not clear what the behaviors are. Basically I lose control and i don't like that | 20:26 |
| clarkb | I like using git locally because then I know what I'm going to produce | 20:26 |
| clarkb | (and can check it before pushing too) | 20:26 |
| clarkb | liek for example rebasing changes in stacks | 20:26 |
| clarkb | I never know what it will do with the rest of the stack so I git rebase -i HEAD~N locally instead then I know | 20:26 |
| gouthamr | true; but i haven't seen a lot of abuse for this | 20:27 |
| fungi | yeah, that's why i never use the rebase and cherry-pick buttons in the gerrit webui | 20:27 |
| fungi | (or revert) | 20:27 |
| clarkb | gouthamr: ya I think the "abuse" is people not getting what they want and pushing 5 times as many new patchsets as necessary to accomplish the goal compared to doing it locally, checking the result and pushing once | 20:27 |
| clarkb | its minor | 20:27 |
| clarkb | I don't actually care if people use them. | 20:28 |
| gouthamr | +1 | 20:28 |
| gouthamr | its annoying to see those patchsets/mistakes/attempts, but, meh | 20:29 |
| gouthamr | in other news, i was rewriting some matrix <---> OFTC doc on manila's contributor doc and had an epiphany to check - its soon going to be 4 years since we moved to OFTC: https://governance.openstack.org/tc/resolutions/20210526-move-irc-to-oftc.html | 20:29 |
| clarkb | gouthamr: have you seen https://github.com/matrix-org/matrix-appservice-irc/issues/1851 ? I think the bridge is broken for new IRC users (their messages don't make it ot matrix) | 20:29 |
| gouthamr | oh, didn't hit this with some new interns this week | 20:30 |
| clarkb | gouthamr: were they using matrix to connect to irc? | 20:30 |
| gouthamr | they joined #openstack-manila just fine | 20:30 |
| gouthamr | yes | 20:31 |
| clarkb | right I think that is fine | 20:31 |
| clarkb | its people on irc that are new that don't go over to matrix | 20:31 |
| gouthamr | oh, the other way around | 20:31 |
| fungi | so the people on matrix end up not seeing messages from some (newer) irc-only users | 20:32 |
| gouthamr | :( | 20:32 |
| clarkb | I'm interpretting the lack of a response on that issue as "we're not investing any effort into the bridge any longer but aren't explicitly shutting it down either" | 20:34 |
| clarkb | I brought up the idea of using matrix natively for opendev in our meeting yesterday | 20:34 |
| clarkb | mostly to throw the idea out so people think about it. No decisions have been made. But I think we're fast approaching "irc + matrix" not being usable without changes | 20:35 |
| * not_gouthamr test | 20:39 | |
| gouthamr | i was able to see that on matrix ^ | 20:39 |
| fungi | so maybe they either fixed it or the problem is more complex | 20:40 |
| gouthamr[m] | not_gouthamr: pinging you from matrix | 20:40 |
| gouthamr | yeah probably | 20:40 |
| gouthamr | for now, hopeful that we can continue to recommend this to new contributors.. they love Element's UI, and for the love of all things holy, i cannot explain how they can chat with us async without a bouncer/paying for a service etc | 20:41 |
| fungi | *cough* mailing lists *cough* | 20:42 |
| fungi | but yes, i understand | 20:43 |
| gouthamr | haha, i wish.. :D | 20:43 |
| fungi | the acl update to opendev/sandbox has now merged requiring Signed-Off-By footers in commit messages, feel free to test whatever you'd like on that repo. i'll be reverting the change at 20:00 utc on friday so you have about 2 days for whatever you can think to test | 21:30 |
| *** gouthamr[m] is now known as identify | 21:44 | |
| *** identify is now known as gouthamr[m] | 21:44 | |
| gouthamr | ty; can you leave it a bit longer fungi? maybe until the end of next week? | 21:49 |
| gouthamr | fungi: also a heads up, i'm workflowing https://review.opendev.org/c/openstack/governance/+/949783 - it's been over 7 days, and discussed well through that time and the requester chimed on the change as well. | 21:52 |
| opendevreview | Merged openstack/governance master: [resolution] Relinquish "quantum" project on PyPI https://review.opendev.org/c/openstack/governance/+/949783 | 21:54 |
| gouthamr | that was quick | 21:55 |
| fungi | the concern raised in #opendev was that our (non-openstack-specific) infra-manual tells users to try out gerrit workflows in the opendev/sandbox repo, and they'll get errors for now if they're not adding signed-off-by to commits, so i was asked to keep it brief | 22:05 |
| gouthamr | yeah :/ | 22:05 |
| fungi | clarkb felt that 3 days was a bit long, but also i might not remember to undo it on a saturday, so i went with 2 days instead | 22:06 |
| clarkb | if you look at the activity in that repo we get a bit about once a week to every few days | 23:12 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!