| gouthamr | tc-members: a gentle reminder that our weekly irc meeting will be held here in ~52 mins | 16:08 |
|---|---|---|
| gouthamr | please find the agenda here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda | 16:08 |
| mnasiadka | gouthamr: I’m off sick, so won’t be able to join | 16:09 |
| gouthamr | mnasiadka: oh :( sorry to hear that, get better soon! | 16:09 |
| cardoe | I'm going to have to miss the 2nd half of the meeting | 16:10 |
| gouthamr | ack | 16:14 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Nov 25 17:00:31 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| 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 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:00 |
| gouthamr | #topic Roll Call | 17:01 |
| gtema | o/ | 17:01 |
| noonedeadpunk | semi o/ - will need to leave in ~20m | 17:02 |
| gouthamr | courtesy-ping: frickler, spotz[m], cardoe, bauzas | 17:03 |
| cardoe | o/ | 17:03 |
| gouthamr | noted absence: m n a sia d k a | 17:03 |
| cardoe | Talking in a different channel. Sorry. | 17:03 |
| gouthamr | no problem; i wonder if the meeting time's being an issue, or, its the end-of-year fever that gets us all :) | 17:05 |
| gouthamr | our attendance is less than quorum, again.. lets get rolling | 17:05 |
| gouthamr | #topic Last week's AIs | 17:06 |
| noonedeadpunk | I think latter :) | 17:06 |
| gouthamr | Reviews on TC resolution on os-net-config handover | 17:06 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/967463 | 17:06 |
| gouthamr | this has a minimum number of votes and can merge anytime now, has been open 7 days.. | 17:07 |
| gouthamr | if you've not looked yet, please do | 17:07 |
| * bauzas joins late | 17:07 | |
| gouthamr | ah quorum! | 17:07 |
| gouthamr | from the last week's meeting, i surmised that you wanted to move the FIPS Goal Objectives to the tracker | 17:08 |
| gouthamr | it's already there :) i think i could do the patch today to move the goal back to "proposed" and start an ML thread with the actions we took at the PTG | 17:09 |
| gouthamr | specifically, asking for help in redefining testing and completion of the goal, reviving failed testing, and stating that the TC is okay with project teams dropping failing jobs in the meantime | 17:09 |
| gouthamr | did i miss anything? | 17:10 |
| gouthamr | the next AI was regarding "PTL Appointment History", i think tonyb took this AI, but we didn't define it completely.. | 17:12 |
| gouthamr | a couple of weeks ago, we discussed a concern that PTL appointments must be preserved on projects.yaml.. and the AI was to write this down somewhere | 17:12 |
| gtema | yes, also last week we were not able to recall details | 17:13 |
| fungi | right, the point was twofold | 17:14 |
| fungi | first, a change in process so we stop wiping the prior list of appointments whena project switches from ptl to dpl model | 17:14 |
| fungi | second, an audit of the git history to find past instances where that happened and restore the missing entries | 17:14 |
| gouthamr | ah +1 | 17:15 |
| gouthamr | okay, tonyb has this detail in the scrollback now, ty fungi | 17:16 |
| gouthamr | next AI was to finish working on the Monasca cleanup patches | 17:16 |
| gouthamr | this looks green now, ty for the deep work on it, frickler: | 17:17 |
| gouthamr | #link https://review.opendev.org/q/hashtag:%22monasca-retirement%22+(status:open%20OR%20status:merged) | 17:17 |
| gouthamr | i messed up the cleanup, i left the LICENSE file in each repo, bad regex :/ so our validation script is failing | 17:18 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/953671 | 17:18 |
| gouthamr | but, i don't want to go and delete those files and adjust the README.rst files etc (because we call out that the repo contents can be restored by checking out HEAD^1) | 17:19 |
| gouthamr | so i added the repos to an ignore list here: | 17:19 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/968268 | 17:19 |
| fungi | a more future-proof approach would be to stop explicitly referring to `git checkout HEAD^1` in the final readme and just use wording that indicates the last pre-retirement state is found in the branch's git history | 17:19 |
| gouthamr | that would be nice | 17:20 |
| fungi | we already have a ton of long-ago retired repositories for which it's no longer accurate anyway due to later changes merging | 17:20 |
| gouthamr | fair, that wording is here: https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#step-2-remove-project-content | 17:21 |
| fungi | i'm happy to review an adjustment to that | 17:22 |
| gouthamr | we didn't need to follow that to the letter, its just a suggestion | 17:22 |
| gouthamr | and was easy to copy-pasta | 17:22 |
| fungi | also openstack could just record a template of its own somewhere like https://docs.openstack.org/project-team-guide/repository.html#step-2-remove-project-content | 17:22 |
| gouthamr | yeah.. | 17:23 |
| fungi | but in this case i do think the wording in infra-manual would be fine to adjust to something more loose, as long as it stays project-neutral | 17:23 |
| gouthamr | +1.. so these patches could merge soon, if you'd like to review, please do.. | 17:24 |
| gouthamr | the next AI was regarding an openstack-discuss ML thread pointing to repositories using passlib to track its removal - was assigned to gtema | 17:25 |
| gtema | oh yes, haven't done this yet, but improved analysis | 17:25 |
| gtema | I updated the PQC wiki adding first actions | 17:25 |
| gtema | will create 4 patches tomorrow agains requirements repo | 17:26 |
| fungi | oh, that reminds me, someone reached out to me wanting to get more involved in security sig activities, and was specifically interested in helping with the pqc stuff | 17:26 |
| fungi | i guess jp's ml thread would be a good starting point for them to get up to speed on it | 17:27 |
| gouthamr | nice, ty for the updates on this | 17:28 |
| fungi | but helping with stuff like passlib replacement would probably be a great place to jump in | 17:28 |
| gouthamr | ++ | 17:28 |
| gtema | there is nothing to do with passlib since it is technically eliminated, just need to cleanup requirements | 17:28 |
| gouthamr | #link https://wiki.openstack.org/wiki/Post_quantum_openstack | 17:28 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/NH7SVJHLRA4ZLH4UINXULFX5SXKVDPZK/ (ML thread on PQC) | 17:28 |
| gouthamr | probably usage in projects that don't adhere to global requirements, mn asiadka mentioned needing to cleanup kolla-ansible | 17:29 |
| fungi | oh, even better (re: passlib) | 17:29 |
| gouthamr | there's this too: https://opendev.org/openstack/bifrost/src/branch/master/playbooks/roles/bifrost-ironic-install/tasks/install.yml#L67 | 17:30 |
| bauzas | thanks for the work on that | 17:30 |
| cardoe | I’ve got to step away | 17:30 |
| gouthamr | ack cardoe.. ty for joining us | 17:31 |
| gouthamr | that's a wrap on AIs | 17:31 |
| gtema | gouthamr - I know there are few cases of tooling still installing it, but we "agreed" last week to just get rid of it in requirements and send out info through the ML - which is what I'll do tomorrow | 17:31 |
| gtema | unless the world explodes tomorrow again | 17:32 |
| gouthamr | ty gtema | 17:32 |
| gouthamr | gtema: no that's scheduled for day after tomorrow | 17:32 |
| gouthamr | #topic OS Manuals could use reviews/help | 17:32 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/openstack-manuals+status:open | 17:32 |
| gouthamr | think we had an impasse regarding this: https://review.opendev.org/c/openstack/openstack-manuals/+/905614 | 17:33 |
| gouthamr | and a related item on oslo's plate: https://review.opendev.org/c/openstack/openstackdocstheme/+/905613 | 17:33 |
| gouthamr | is there a way to compromise on this? Can we advertise that we're tracking users to generate metrics and help us improve OpenStack; and suggest how to disable this tracking? | 17:35 |
| fungi | while those are changes i pushed, i have no vested interest in either approach (accepting them or ripping that stuff out entirely) | 17:35 |
| gouthamr | my view is that i'd accept the changes and then seek another change to rip them out.. | 17:37 |
| gtema | than leave such review | 17:37 |
| fungi | tonyb also pointed out that we have similar outdated scripts in the openstack wiki theme which would need to be redone for one of the more recent versions we're planning to upgrade through | 17:37 |
| gouthamr | is the wiki theme maintained on git too? | 17:38 |
| fungi | no | 17:39 |
| fungi | we don't (yet) have any config management/deployment automation for the mediawiki server, that's something tonyb has been working on | 17:39 |
| gouthamr | so technically, there are aspects that can be changed, enabled/disabled without any of us needing to review | 17:40 |
| fungi | right | 17:40 |
| fungi | it's something that was manually set up by a wmf staffer when we converted from moinmoin to mw, and they had committed to managing the server themselves back in the days before we insisted on having configuration management | 17:40 |
| fungi | but then they moved on to other things and the server has been semi-abandoned since | 17:41 |
| fungi | because turning a giant pile of php into a configuration-managed system wasn't anything the rest of us had time for | 17:42 |
| gouthamr | yeah :( yet its a significant resource for the community | 17:42 |
| gouthamr | are there any other opinions to note wrt this change? | 17:42 |
| gouthamr | two +2s would mean it can be merged; i'll add mine and close it out unless you tell me we need a bit longer to consider it | 17:44 |
| gouthamr | #topic Python PTI and test runner guidance | 17:45 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/3V3CNPQLB77SKFVLZ6LXJ5NPNYWW4QFD/ (Request for guidance on improving Python PTI doc to include pytest for Horizon plugins testing) | 17:46 |
| gouthamr | think this thread went in different directions and i learned a few new things | 17:47 |
| fungi | the resolution seems to be where chandan says "Watcher team is going with unittests module for writing watcher-dashboard integration tests." | 17:48 |
| gouthamr | i think we've established that there's no problem pursuing pytest based tests, and we're asking the horizon team to explore if those tests can be run with stestr | 17:48 |
| gtema | nope - stestr is not part of the issue at all | 17:49 |
| gtema | not the runner is the "question", but the test itself | 17:49 |
| gtema | we have projects using pytest to run unittests already | 17:50 |
| fungi | right, pytest the runner is compatible with the unittests module's interfaces. pytest the module has additional test building blocks that don't work with a lot of other test runners | 17:50 |
| clarkb | this situation is one where I think we should start from our goals first | 17:51 |
| clarkb | whether or not anyone is using it already is beside the point. | 17:52 |
| gtema | +1 | 17:52 |
| clarkb | and as I stated on the mailing list thread I don't think pytest is in opposition to the goals we have today | 17:52 |
| bauzas | why people want to use pytest ? | 17:53 |
| clarkb | specifically being able to run in parallel to take advantage of test resources and the ability to run in places like IDEs | 17:53 |
| fungi | prior discussions also uncovered that the horizon team's implementation was due to the developers who wrote it not being familiar with existing convention within openstack, and then the team simply didn't want to redo that work later once it was already written | 17:53 |
| bauzas | just an open question | 17:53 |
| gtema | bauzas - because it is usually simpler, and slimmer | 17:53 |
| gouthamr | yes, so its reasonable to ask if they can run these tests in parallel, and produce a subunit o/p | 17:53 |
| clarkb | bauzas: pytest the test runner has some generally nice features for developers when debugging tests. Pytest the library is a lot less verbose than unittest the library | 17:53 |
| bauzas | well, I can pdb dito ;-) | 17:54 |
| clarkb | in the thread fixture creation management was specifically called out | 17:55 |
| clarkb | you can totally write fixtures taht work with unittest and don't rely on pytest, but it sounds like people like the pytest fixture approach | 17:55 |
| clarkb | gouthamr: yes that seems reasonable: basically capture that our assumptions are correct then move on | 17:56 |
| gouthamr | #link https://governance.openstack.org/tc/reference/pti/python.html#python-test-running | 17:56 |
| gouthamr | i think we can lead the discussion there, i agree that if this is encoded in the CI jobs, it'll catch the introduction of weird incompatible patterns/plugins that're possible with pytest | 17:57 |
| gouthamr | anything else to round up this discussion? | 17:59 |
| gtema | gouthamr - there are already quite a few projects using pytest instead of stestr, so this "guideline" is not fulfilled anymore | 17:59 |
| gouthamr | yes; i think we did a code search to identify these | 18:00 |
| frickler | oops, I messed up meeting timing again. I blame downstream noise. reading backlog now | 18:01 |
| gouthamr | np frickler; its time to wrap up | 18:01 |
| gouthamr | anything to note for the minutes today? | 18:02 |
| fungi | the other projects brought up as existing examples of pytest use within openstack were cases in which the implementation was written before the projects became part of openstack, so essentially inherited/transplanted use | 18:02 |
| fungi | not that it's necessarily a problem, just context | 18:03 |
| gouthamr | ++ | 18:03 |
| gouthamr | okay, thank you all for joining.. i'll punt the rest of the topics to next week | 18:04 |
| gouthamr | if there's anything pressing, please do continue the discussion here | 18:04 |
| gouthamr | #endmeeting | 18:04 |
| opendevmeet | Meeting ended Tue Nov 25 18:04:22 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-25-17.00.html | 18:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-25-17.00.txt | 18:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-25-17.00.log.html | 18:04 |
| sean-k-mooney | gouthamr: the pytest topic was orginally a problem that i raised at the ptgu specific calluing out th use of pytest fixture or pytest as a lib as proiblematic | 18:23 |
| sean-k-mooney | pytest as a test runner is fine | 18:23 |
| sean-k-mooney | on the watcher side we are plannign to do some pocs of diffent aprpoches, no descison has been made but we will be starting with unittest + (selenitum vs playwright) to compare the ux fo writing/reviewing tests with both | 18:24 |
| sean-k-mooney | we will likely compare that ot the pytest based test as well | 18:25 |
| sean-k-mooney | but im not generaly a fan of the pytest fixutre approch | 18:25 |
| sean-k-mooney | lets boiler plate but also more magic that is harder to debug/think about | 18:26 |
| sean-k-mooney | which is the pros and cons of runtime depency injection and asert rewriting that pytest brings | 18:27 |
| gouthamr | sean-k-mooney: i see, i don't see our PTI preventing that though.. it's only clarified the "test runner" bit.. with any testing we'd like to ensure there is a "real time subunit output" and "support for parallel execution of tests". There's a note that the test runner we've chosen (stestr) "only runs tests conforming to the python stdlib unittest module".. | 21:03 |
| gouthamr | when you diverge and use pytest, you can end up using arcane patterns that'll become a maintenance burden for the community | 21:03 |
| gouthamr | i.e., there's a risk.. but, the fixtures approach for one seems like a preference? help me understand :D ty for sharing the watcher team's approach to this. very glad you brought this up because, i, like the horizon folks, didn't really read teh PTI properly and understand the context for these past decisions! | 21:05 |
| sean-k-mooney | the pti in my mind directly probiths any use of pytest as a lib | 21:07 |
| sean-k-mooney | which was somthign we reinfoced in teh rquriement repo for year by not allowing it ot be listed at all | 21:07 |
| sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/pti/python.rst#python-test-running | 21:07 |
| sean-k-mooney | if we read that its say "stestr only runs tests conforming to the Python stdlib unittest model (and extensions on it like testtools)." | 21:08 |
| sean-k-mooney | using pytest as a libary creates testcases that do not conform to that requirement | 21:08 |
| gouthamr | if your research can show that this is possible without pytest, maybe you'll have converts | 21:12 |
| sean-k-mooney | gouthamr: my over all concer is not about usign it as a test runner | 21:12 |
| sean-k-mooney | it about useing it to write tests | 21:13 |
| gouthamr | yes, ty for clarifying - i do want to chase down the other aspects of the PTI though while we're discussing this | 21:15 |
| sean-k-mooney | i brought this up when pytest was being dicsued in https://review.opendev.org/c/openstack/requirements/+/712315 | 21:16 |
| gouthamr | i.e., these integration tests currently don't conform to those report and parallelization requirements, so can they with relative ease? | 21:16 |
| sean-k-mooney | at the time i als dint really feel that using it as a test framework was a good thing | 21:16 |
| sean-k-mooney | but i didnt obejct strongly since it was not going to directly affect me day to day | 21:16 |
| sean-k-mooney | gouthamr: https://pypi.org/project/pytest-subunit/ exits but has not been updated in a hile | 21:17 |
| gouthamr | yes | 21:17 |
| sean-k-mooney | the paralisation for those test by there nature cant alwsy be suprpoted but some of it could be | 21:18 |
| gouthamr | i found it through your comment on that very change during the PTG, and sigh, i don't know if it works and is reliable to use | 21:18 |
| sean-k-mooney | to be clear if the parallisum and subunit reporting were adressed | 21:18 |
| sean-k-mooney | it woudl not adresss my concern at all about using pytest | 21:18 |
| gouthamr | we seem to be using https://libraries.io/pypi/pytest-html at the moment in these integration test jobs | 21:18 |
| sean-k-mooney | that is focusing on the test runner part | 21:19 |
| sean-k-mooney | which i dont have an issue with | 21:19 |
| gouthamr | ack | 21:19 |
| sean-k-mooney | yes pytest-html sever a similar function for humans | 21:19 |
| clarkb | sean-k-mooney: gouthamr I don't think the PTI says anything about libraries does it? | 21:19 |
| clarkb | its just that some libraries may not be compatible with all test runners | 21:19 |
| gouthamr | yes it doesn't | 21:20 |
| sean-k-mooney | pytest test case adn fixture arnt runable with stestr | 21:20 |
| sean-k-mooney | unless that has magiclly changes recently | 21:20 |
| clarkb | correct (nor unittest.main or nose) | 21:20 |
| gouthamr | mtreinish called this out in his comment on that requuirements change: "We've had this discussion of why not pytest many times over the years and wrote down the reasoning in the project testing interface" | 21:20 |
| sean-k-mooney | right and that is requird by the pti | 21:20 |
| clarkb | right but the reasons it is required by the pti are no longer at odds with pytest | 21:21 |
| clarkb | which is why I keep trying to get us back to thinking about goals and objectives first | 21:22 |
| clarkb | the goal is to take advantage of the ci system while allowing developers to use whatever tool they prefer locally | 21:22 |
| clarkb | IDE or whatever | 21:22 |
| sean-k-mooney | well i tough one of the goal was to ahve a commoen test framework | 21:22 |
| clarkb | not in the pti it doesn't say anything about the tests themselves | 21:23 |
| sean-k-mooney | that now how i read "testr only runs tests conforming to the Python stdlib unittest model (and extensions on it like testtools)." | 21:24 |
| sean-k-mooney | i read that as your test must be witen with the stdlib unitests and it exetions | 21:24 |
| sean-k-mooney | which pytest is not | 21:25 |
| clarkb | yes, because doing so enabled the other goals. I'm not sure it wqs ever a strict goal on its own | 21:25 |
| clarkb | its a consequence of the decisions made to achive the other goals | 21:25 |
| sean-k-mooney | oh because i woudl condier that core to the pti | 21:25 |
| sean-k-mooney | not a side effect | 21:25 |
| sean-k-mooney | which is why i rased this in the first place | 21:26 |
| clarkb | note many people can and do use other testing tools that work fine becaus they are standard compatible | 21:26 |
| clarkb | fixtures for example | 21:26 |
| clarkb | they are not part of the standard | 21:26 |
| clarkb | even mock was at one time non standard iirc | 21:26 |
| clarkb | (but it again was compatible with the standard tooling) | 21:26 |
| sean-k-mooney | right i knwo it an extention to the standard set | 21:28 |
| sean-k-mooney | we use to have difent workdin tin the past https://github.com/openstack/governance/blob/91b7b8af4a4534fb23fb1348c3e9f4a1650af404/reference/pti/python.rst?plain=1#L72-L81 | 21:28 |
| sean-k-mooney | that was revisted by https://github.com/openstack/governance/commit/759c42b10cb3728f5549b05f68e826b1c62a968c | 21:29 |
| sean-k-mooney | we used to be very explict that we buidl on top of https://opendev.org/openstack/oslotest and the depenciy it combines | 21:32 |
| sean-k-mooney | i.e. fixutre and testtools | 21:32 |
| sean-k-mooney | in the past we use mox instead of mock the lib and then eventually we moved to unittest.mock | 21:33 |
| sean-k-mooney | when we got rid of python 2.7 support | 21:33 |
| clarkb | right so I guess this goes back to what our goals are. Is it just ensuring we can adequately take advantage of ci resources and allow devs to use their IDEs too. Or do we also see value in consistency of actual test library tooling for the tests themselves | 21:34 |
| clarkb | the current iteration of the docuemnt seemst o have relaxed the second thing | 21:34 |
| sean-k-mooney | right the second thing is what i saw value in as tooling is easy to change btu leaning how a test framwork works i harder IMO | 21:35 |
| sean-k-mooney | anyway i better run before stores start closing for the night o/ | 21:36 |
| sean-k-mooney | if the opion of the tc is that pytest as a lib is consitent with the pti then i can take that impact back to the watcher team | 21:37 |
| sean-k-mooney | and we can decied seperatly fi the cost of learning pytest is worth the benift of the shared code with horizon | 21:37 |
| * gouthamr writes for when you return | 21:53 | |
| gouthamr | sean-k-mooney: i am leaning on the side of: if project teams think that there's benefits in pytest, and it can conform to consistency that we've built around test tooling, by all means, explore it - but please be careful not to violate the desire for maintainability. Ease of use and familiarity for one person, or a small subset of people shouldn't be the motive to drive this decision | 21:55 |
| gouthamr | it should be that we can sustain testing this way beyond our involvement with the project. | 21:55 |
| gouthamr | which is why i'm supportive of the watcher team exploring our familiar toolkit: unittest + testtool extensions, to try the same sorta testing and showing us the way.. | 21:57 |
| gouthamr | if that's a burden you're unwilling to bear, it's totally fair to collaborate with horizon and other UI folks that are going down the pytest path.. except we've to resolve these PTI/test runner capability questions | 21:58 |
| sean-k-mooney | right the deisre for mantianablity and constisntsy is what intially tells me not to use pytest | 21:59 |
| sean-k-mooney | we dont have expice with it so in addtion learning ot write test in playwright or selenium | 21:59 |
| sean-k-mooney | we woudl have to also do so in a testing framework we do not have expsrince with | 22:00 |
| gouthamr | fair enough :) someone on the thread noted (i'm paraphrasing) that the wider python community seems to be gravitating towards pytest, and mayyybe we may get some non-openstack python contributors helping us in the long run | 22:01 |
| sean-k-mooney | i feel liket that unlikey but maybe | 22:01 |
| clarkb | I suspect that wher eyou might get value from that is less in attacting new contributors and more in using tools LLMs are more familar with | 22:12 |
| sean-k-mooney | no that i cna belive | 22:13 |
| sean-k-mooney | that one of the resons im interesting in playwright over selenium | 22:13 |
| sean-k-mooney | as playwright seams to be winding there massivly in the llm space | 22:13 |
| sean-k-mooney | *playwright seams to eb winning... | 22:24 |
| opendevreview | Merged openstack/openstack-manuals master: Update analytics tracking ID https://review.opendev.org/c/openstack/openstack-manuals/+/905614 | 22:45 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!