| dalees | hello TC, could I request a topic update of channel #openstack-containers - the meeting time and frequency has changed, so please update to "Meeting: alternate Tuesdays @ 8AM UTC" | 01:16 |
|---|---|---|
| dalees | for confirmation see meeting agenda etherpad, meeting notes and mailing list post. | 01:17 |
| gouthamr | hey dalees : someone from opendev-infra can help with that request (ping: fungi frickler)… you may also want to edit this: https://meetings.opendev.org/#Magnum_Team_Meeting | 02:03 |
| gouthamr | dalees: the source for that is: https://opendev.org/opendev/irc-meetings/src/branch/master/meetings/magnum-team-meeting.yaml | 02:03 |
| opendevreview | Merged openstack/openstack-manuals master: Remove installation guide for openSUSE/SLES https://review.opendev.org/c/openstack/openstack-manuals/+/948834 | 02:04 |
| gouthamr | dalees: you could also request to be an operator on the #openstack-containers channel by editing https://opendev.org/openstack/project-config/src/commit/4ffb3a6cd88fa85c12ce3f02063210b4099305ed/accessbot/channels.yaml#L163 | 02:07 |
| gouthamr | that would let you set the channel topic etc by chatting with ChanServ | 02:08 |
| gouthamr | here are some docs: https://docs.opendev.org/opendev/system-config/latest/irc.html | 02:09 |
| opendevreview | OpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals https://review.opendev.org/c/openstack/security-doc/+/950207 | 02:12 |
| dalees | gouthamr: thank you for those links, I will update the meetings repo with the new info. | 04:09 |
| fungi | tc-members: please see https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/A7S24NMKOQZFXRAAEEYQX23S6UF4WML2/#A7S24NMKOQZFXRAAEEYQX23S6UF4WML2 as i mentioned last week. short notice but could be worth trying to squeeze into the agenda if possible | 12:51 |
| gouthamr | Ty, I added it to the tc meeting last night | 13:40 |
| fungi | awesome, much appreciated | 14:15 |
| JayF | fungi: \o/ \o/ \o/ \o/ \o/ | 14:26 |
| fungi | technical implementation for that will be trivial. documentation updates will be the bigger amount of work, and communicating workflow changes (git commit -s) to our contributor community of course | 14:28 |
| JayF | yeah, CI validation that DCO was done will be crucial | 14:31 |
| JayF | doesn't help that some projects used to -1 specifically for adding a DCO line even though it wasn't needed | 14:32 |
| clarkb | we wouldn't do it in CI. We would have gerrit enforce it same as with the CLA today | 14:32 |
| JayF | Gerrit enforcing it is in CI from a UX even if not an engineering perspective :D | 14:35 |
| JayF | CI = robots telling us to be better :D | 14:35 |
| fungi | not ci, commits get rejected before they're even pushed | 15:00 |
| fungi | not reported in the ui at all, reported in command-line error responses to the user | 15:00 |
| fungi | the ci system is not involved at all | 15:01 |
| JayF | ah, nice, that's how it works in Gentoo | 15:07 |
| *** ralonsoh is now known as ralonsoh_out | 15:08 | |
| fungi | as clarkb noted, it's the same as how the icla is enforced today, your push is refused if you haven't signed one and you just get the error back (from gerrit) during the git push | 15:10 |
| JayF | I believe back when I first openstack'd, it would let you push without CLA and some robot fussed at you about it | 15:14 |
| JayF | but that's long enough ago now that could just be a false memory | 15:14 |
| fungi | it's always been enforced at push, in the early days it was done with a gerrit group of who was approved to push and then we synced user ids from a launchpad team where volunters added people after checking icla agreement mssages manually | 15:16 |
| fungi | later gerrit added a cla enforcement feature and we tied that to gerrit's contact information form to do a backend api check to the foundation member database | 15:17 |
| fungi | but when gerrit dropped the contact filing feature we ceased checking that each cla matched up to a foundation membership (which was never required by the bylaws anyway) | 15:18 |
| fungi | note that only deliverable repos for openstack were traditionally set to require a cla, some repos like infra ones allowed users with no cla to push | 15:18 |
| fungi | pre-gerrit used the same launchpad team tied to permissions for pushing to lp's bazaar, which is why we ended up with that situation initially for the transition to gerrit | 15:22 |
| JayF | Honestly at this point I'm mainly impressed with how well you can recollect all this :D | 15:23 |
| fungi | switching our cla enforcement from the launchpad team sync to gerrit's cla feature was one of my first projects after moving from hp to foundation staff employment in 2013 | 15:24 |
| noonedeadpunk | `git commit -s` - I also wonder about quirks with IDE integrations | 15:43 |
| clarkb | It is a common process for many projcets. I expect any IDE with git integration can add it | 15:44 |
| fungi | enough big projects already require it (linux kernel, kubernetes, etc) | 15:44 |
| fungi | i'd be surprised by any ide which had a problem with that | 15:45 |
| noonedeadpunk | yes, I know, which is sort of annoying to deal with | 15:45 |
| noonedeadpunk | as not all of them do it "right" | 15:45 |
| noonedeadpunk | and respect the author changes | 15:45 |
| noonedeadpunk | (maybe it's already fixed) | 15:45 |
| noonedeadpunk | ok, it's probably fine now indeed | 15:48 |
| noonedeadpunk | so disregard :) | 15:48 |
| JayF | You can also update git config to automatically do DCO | 15:48 |
| JayF | (git config --global format.signoff true) | 15:49 |
| noonedeadpunk | yeah, right, I jsut found that in man :D | 15:51 |
| clarkb | note the note in the manpage | 15:57 |
| clarkb | "Note: Adding the Signed-off-by trailer to a patch should be a conscious act and means that you certify you have the rights to submit this work under the same open source license." | 16:02 |
| gouthamr | tc-members: a gentle reminder that we're gathering here for our weekly meeting in ~58 mins | 16:03 |
| cardoe | I’m in the Scottish highlands. Won’t make it. But ping on anything to review and I will when I am back at the hotel tonight. | 16:03 |
| gouthamr | cardoe: ack | 16:04 |
| gouthamr | enjoy your vacation! | 16:04 |
| cardoe | Thanks! | 16:04 |
| fungi | make sure to have some irn-bru | 16:05 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Fix outdated info on the tc-guide https://review.opendev.org/c/openstack/governance/+/950446 | 16:50 |
| * frickler needs to skip the meeting, too, sorry | 16:57 | |
| gouthamr | frickler: ack | 16:57 |
| gouthamr | #startmeeting tc | 17:00 |
| 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 |
| 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:00 |
| mnasiadka | o/ | 17:01 |
| gouthamr | noted absence: c a r d o e, s p o t z, f r i c k l e r | 17:01 |
| noonedeadpunk | o/ | 17:01 |
| gouthamr | courtesy ping: gmaan, gtema, bauzas | 17:01 |
| gmaan | o/ | 17:01 |
| bauzas | here but on another meeting | 17:02 |
| gouthamr | we've a smaller-than-usual crowd today.. lets get started | 17:05 |
| gouthamr | #topic Last Week's AIs | 17:05 |
| gouthamr | i don't think we took many.. | 17:05 |
| gouthamr | we spent a while discussion governance proposals on gerrit, and the discussion continued in the respective patches | 17:06 |
| gouthamr | these have been updated, and could use reviews | 17:06 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/governance+status:open (Open reviews on the governance repo) | 17:07 |
| bauzas | ack | 17:08 |
| gouthamr | a couple of other AIs pertain to topics we're discussing today | 17:08 |
| gouthamr | contributor experience, and the topic regarding ICLA/DCO | 17:09 |
| noonedeadpunk | Am I right that we never heard back from person who asked for quantum? | 17:09 |
| fungi | i don't think they were asked any questions | 17:09 |
| gouthamr | i did | 17:09 |
| gouthamr | privately | 17:09 |
| noonedeadpunk | did you get any responce | 17:10 |
| gouthamr | i sent them an email 21 hours ago, stating this: | 17:10 |
| gouthamr | "A member of the OpenStack Technical Committee wanted you to comment | 17:10 |
| gouthamr | on, or support this request with a "+1": | 17:10 |
| gouthamr | https://review.opendev.org/c/openstack/governance/+/949783/comments/087aa18a_d00f2fcf | 17:10 |
| gouthamr | Would you be able to do that? You would need to sign up for an account | 17:10 |
| gouthamr | on https://review.opendev.org. If you're not comfortable doing that, | 17:10 |
| gouthamr | feel free to share any insights on the mail thread, and we'll still | 17:10 |
| gouthamr | consider it your position." | 17:10 |
| gouthamr | no response yet | 17:10 |
| gmaan | nit irrespective of their response/question, proposed resolution is good way to give go ahead from us. | 17:11 |
| gmaan | implementation can be done now or later depends on need | 17:12 |
| gouthamr | i was going to jinx by stating the same thing :) | 17:12 |
| gouthamr | this resolution has gathered enough RC votes to merge.. it was last updated a week ago | 17:13 |
| gmaan | ++ | 17:13 |
| noonedeadpunk | Well, I mean, won't it be weird situation to have a resolution and get stuck with it? | 17:13 |
| gouthamr | stuck with? | 17:13 |
| noonedeadpunk | as if we won't transfer control, it would be weird to have it | 17:13 |
| gouthamr | you mean if the person doesn't want this anymore? | 17:13 |
| noonedeadpunk | yeah | 17:13 |
| gouthamr | ah, we | 17:13 |
| gouthamr | have clarified the next steps | 17:13 |
| 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 |
| gmaan | than it can be used as approval/ref for future if anyone need | 17:14 |
| gouthamr | they can delete the project if they wish | 17:14 |
| JayF | That said, I would not take their lack of gerrit participation as a sign of disinterest | 17:14 |
| 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 |
| noonedeadpunk | JayF: and reply to email thread they've started? | 17:14 |
| JayF | clarkb: ++ | 17:14 |
| gouthamr | JayF: i didn't, which is why i suggested they just respond on the mail thread they started | 17:14 |
| clarkb | even if they already had a gerrit account it feels superfluous | 17:14 |
| JayF | gouthamr: ah, I misread | 17:14 |
| gmaan | clarkb: ++ | 17:14 |
| fungi | it's way more red tape than we went through when we handed over reddwarf a few months ago, fwiw | 17:15 |
| gmaan | resolution/merging it etc are internal way to support their request, we do not need them to re-confirm on multiple places | 17:15 |
| 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 |
| gouthamr | i agree, however, multiple people on the TC expressed the desire to formalize this.. and i respect that | 17:16 |
| gouthamr | i don't know if we'd care about all of the other names the same way | 17:16 |
| 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:16 |
| 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 |
| noonedeadpunk | so I'm inventing smth which is totally unnecessary here | 17:17 |
| noonedeadpunk | yeah, right | 17:18 |
| gouthamr | any other AIs to discuss/ | 17:19 |
| gouthamr | lets move on | 17:19 |
| gouthamr | #topic CLA to DCO | 17:19 |
| gouthamr | #link https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/thread/PXMTX67TRL2B4ONICTT2E2XZLG4J4LAL/ | 17:19 |
| gouthamr | jbryce _may_ be here.. | 17:20 |
| jbryce | i am! | 17:20 |
| gouthamr | #link https://developercertificate.org/ (Developer Certificate of Origin) | 17:20 |
| gouthamr | hey there jbryce | 17:20 |
| 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 |
| 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:21 |
| bauzas | looks to me a good change | 17:22 |
| 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 |
| gouthamr | so we have a timeline too ^ | 17:22 |
| gouthamr | ttx pointed us to the old TC resolution to this regard | 17:22 |
| gouthamr | #link https://governance.openstack.org/tc/resolutions/20140909-cla.html | 17:23 |
| gmaan | Even this was resolution for request from TC to board | 17:23 |
| 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 |
| 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 |
| gmaan | and this time is coming from board which matches both side desire to move to DOC | 17:23 |
| 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 |
| gmaan | jbryce ++ | 17:23 |
| 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 |
| gouthamr | i don't think it can be smooth | 17:24 |
| 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 |
| 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:24 |
| bauzas | while I'm fine with the move forward, I wonder about the interim period | 17:25 |
| gouthamr | how would it look if it wasn't an immediate cut-over? | 17:25 |
| noonedeadpunk | fungi: but can we distinguish DCO from CLA user in CI? | 17:25 |
| fungi | ci doesn't come into the picture | 17:25 |
| fungi | we enforce it with gerrit permissions | 17:25 |
| gmaan | yeah | 17:25 |
| noonedeadpunk | oh, ok | 17:26 |
| gouthamr | JayF noted earlier that gerrit enforcement is CI according to the developer "UX" :D | 17:26 |
| noonedeadpunk | so if no signed-off in commit message but user has signed CLA - it is fine? | 17: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 |
| 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 |
| gmaan | and it can be valid (I mean format for commit msg) from the new commits | 17:26 |
| bauzas | fungi: would it be transparent for our contributors ? | 17:26 |
| noonedeadpunk | liek gerrit will pass it? | 17:26 |
| JayF | better than CI if it gives feedback on push :D | 17:26 |
| jbryce | as far as timing, ideally there would be a clean cutover where no one signs a CLA after May 31 | 17:26 |
| fungi | bauzas: no, contributors will need to use a different workflow (git commit -s or add a config option to their git tooling) | 17:26 |
| 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 |
| clarkb | (you can require one, the other, or both but not either) | 17:27 |
| gouthamr | jbryce: ah, makes sense.. a sunset date to grey out the ICLA | 17:27 |
| noonedeadpunk | so it will be immediate cut-off then | 17:27 |
| bauzas | Ah, Signed-Off I see | 17:27 |
| 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 |
| bauzas | then my main concern is again about the deadline we have | 17:28 |
| fungi | we have no deadline afaik | 17:28 |
| noonedeadpunk | I don't think we have a deadline | 17:28 |
| noonedeadpunk | or well, we can define that | 17:28 |
| bauzas | cool then | 17:28 |
| gmaan | only question I have is, do we need to update existing in-progress commit with Signed-Off ? | 17:29 |
| noonedeadpunk | so we have time to prepare docs, communication, etfc | 17:29 |
| 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 |
| noonedeadpunk | If it's gerrit ACL, I'd imagine that yes, if one needs to be updated | 17:29 |
| 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:29 |
| fungi | gmaan: from what i understand, the tc can decide what timeline they want once we get confirmation that it's allowed | 17:30 |
| fungi | this isn't a deadline imposed from outside | 17:30 |
| 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:30 |
| 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 |
| jbryce | gmaan: i think we can say it would be for contributions post May 31, not existing in process contributions | 17:31 |
| gmaan | ++, that will be easy implementation then | 17:31 |
| bauzas | ah cool | 17:31 |
| jbryce | fungi: no it is not related to the delaware corp at all | 17:32 |
| gouthamr | noob question: we'd enforce this on new patches to ongoing/open changes too? | 17:32 |
| gmaan | jbryce: maybe something we can explicitly state in board approval? or maybe in TC resolution if we push that | 17:32 |
| 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 |
| fungi | so if they wanted it to be effective starting january 2026, for example, that would still be allowed? | 17:32 |
| jbryce | there is no board approval required for it. it's really down to the projects to agree and implement | 17:32 |
| fungi | (not that i expect it would take that long) | 17:32 |
| 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 |
| gmaan | ohk. then fine. | 17:33 |
| fungi | wait, so it *does* have to be switched prior to june 1? that seems counter to what was presented previously | 17:34 |
| fungi | that doesn't really give any time to update documentation and notify contributors | 17:34 |
| JayF | June ... 2025? Like in two weeks? | 17:34 |
| noonedeadpunk | that can be problematic then as it's just 10 days to collect the feedback/agreement and prepare docs/recommendations | 17:34 |
| gouthamr | the only doc i see that needs updating is this one: | 17:34 |
| gouthamr | https://opendev.org/openstack/contributor-guide/src/branch/master/doc/source/common/setup-gerrit.rst | 17:34 |
| gmaan | yeah, in 10 days | 17:34 |
| bauzas | yeah | 17:35 |
| gouthamr | we've not called out CLA/ICLA anywhere else afaik | 17:35 |
| 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 |
| JayF | gouthamr: And endless internal onboarding documentation which might refer to CCLA/ICLA | 17:35 |
| bauzas | that's very short in time | 17:35 |
| noonedeadpunk | and sort out for orgs who signed CCLA | 17:35 |
| 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:35 |
| noonedeadpunk | and if /how they should legally approach changes | 17:36 |
| * JayF == noonedeadpunk | 17:36 | |
| jbryce | so it's either new CLAs for the new entity or a switch to DCO (or both sequenced in whatever timeframe) | 17:36 |
| JayF | This will require re-evaluation of contribution policies in some orgs | 17:36 |
| 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 |
| JayF | and so we should be very careful about taking rapid action | 17:36 |
| 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 |
| 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:36 |
| bauzas | do we really want to block proposals ? | 17:37 |
| gmaan | clarkb: perfect, then it is much easy to communiocate | 17:37 |
| fungi | what is the legal risk of we don't make the june 1 deadline? | 17:37 |
| 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 |
| gmaan | it is not block, it is a very easy thing to do. and many commit msg/developer already do the same | 17:37 |
| fungi | the "cut over" will be users getting errors when they try to push new changes or revisions to existing changes | 17:37 |
| gouthamr | #link https://gerrit-review.googlesource.com/Documentation/user-signedoffby.html (Gerrit implementation doc) | 17:37 |
| 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:37 |
| fungi | errors at the git command line (not ci/webui errors) | 17:38 |
| clarkb | it avoids awkward situations where something is pushed that you then have to pretend never existed | 17:38 |
| 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 |
| 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 |
| noonedeadpunk | yeah, right, I agree it's better overall | 17:38 |
| 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 |
| noonedeadpunk | but seems that reality is pointing towards support of check of either old CLA or DCO | 17:39 |
| 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 |
| bauzas | that would be ideal | 17:39 |
| noonedeadpunk | gmaan: they may not be _allowed_ by internal policy / legal team | 17:39 |
| 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 |
| gouthamr | to use the DCO? | 17:40 |
| noonedeadpunk | it's not that they can't do it | 17:40 |
| noonedeadpunk | gouthamr: to push patch outside fo the org | 17:40 |
| gouthamr | seems weird, all it says it, i accept whatever license that's on the file i'm editing | 17:40 |
| 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 |
| gmaan | Is it? I am not sure DCO are blocked by org.? but I might be wring | 17:40 |
| gmaan | wrong | 17:40 |
| JayF | gmaan: it's more about the conditions of contribution being laid out in detail in policy | 17:40 |
| fungi | however, mixing cla and dco enforcement would require both (agreeing to a cla and adding signed-off-by to their commits) | 17:40 |
| 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 |
| fungi | so when we turn on dco enforcement it would make sense to turn off cla enforcement | 17:41 |
| noonedeadpunk | you might be blocked by your contract as contributions are IP of the comany | 17:41 |
| jbryce | agree. if we implement dco, i would not want to mix it with CLA for a variety of reasons | 17:41 |
| gmaan | JayF: i see. | 17:41 |
| noonedeadpunk | and CCLA could be treated by some as official agreement to push data to | 17:41 |
| JayF | noonedeadpunk: that's /exactly/ how it was treated at the place I'm thinking | 17:41 |
| noonedeadpunk | but I'm not a lawyer, and not sure these lawyers are right, but I know that such things totally exist | 17:42 |
| noonedeadpunk | right | 17:42 |
| 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 |
| 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 |
| 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:42 |
| gmaan | unless istio past case of changing governance etc but that was a big change from other organization perspective | 17:43 |
| 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:43 |
| 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 |
| 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 |
| 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:44 |
| noonedeadpunk | I'd say if we have to sign new CLA for all who signed old one - better go with DCO | 17:45 |
| bauzas | agreed | 17:45 |
| noonedeadpunk | as both cases will be equally blockers | 17:45 |
| JayF | ++ | 17:45 |
| noonedeadpunk | and DCO is just eaier/more wise choice overall | 17:45 |
| 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 |
| bauzas | yeah all is about the upgrade impact | 17:45 |
| bauzas | if we expect contributors workflow changes, then please request DCO rather than signing a new CLA | 17:46 |
| 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 |
| gmaan | yeah, downstream policy checks valid for new CLA also | 17:46 |
| noonedeadpunk | at least through affilation, not as a private person in my free time | 17:47 |
| gmaan | DCO makes things easy for developers as downstream checks 3etc | 17:47 |
| gouthamr | noonedeadpunk: interesting, has that got anything to do with the kubernetes's licensing or contributor agreement? | 17:47 |
| 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 |
| noonedeadpunk | it6 has to do with an explicit list of organizations being maintained | 17:48 |
| noonedeadpunk | again. I guess it won't be a problem after all, but it might need some time to get approvals | 17:48 |
| noonedeadpunk | and also we don't have the strictest rules from what I've heard | 17:49 |
| JayF | None of it is hard with sufficient notice; the 10 days is what really makes it difficult. | 17:50 |
| noonedeadpunk | ++ | 17:50 |
| gouthamr | ack, jbryce noted this conclusion, and took an AI | 17:50 |
| jbryce | yeah i also wish we would have realized this earlier | 17:51 |
| gmaan | meanwhile in parallel, do we want TC to start the formal vote as part of resolution or so? | 17:52 |
| noonedeadpunk | maybe we should start writing resolution regardless? | 17:52 |
| gmaan | yeah | 17:52 |
| gouthamr | how would you resolve something that you've already resolved to? | 17:52 |
| gouthamr | i mean, should we call out the CLA changes as well as the DCO enforcement in one go here? | 17:52 |
| 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 |
| noonedeadpunk | set a transition date of 1st of june :) | 17:53 |
| gmaan | old one is request to board about DCO approval but new one will make confirmation about current requst | 17:53 |
| gmaan | and more about transition dates etc | 17:53 |
| bauzas | +1 communication is key | 17:53 |
| bauzas | a resolution would be the first document | 17:54 |
| gouthamr | ack.. we can debate the date after jbryce follows up on this? | 17:54 |
| noonedeadpunk | it doesn't sound like there's much choice atm... | 17:54 |
| 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 |
| bauzas | fwiw, we only have one TC meeting left before June 1 | 17:54 |
| noonedeadpunk | if we go with path of new CLA - then yeah, we can | 17:54 |
| fungi | and we can have documentation updates staged to merge at roughly the same time | 17:55 |
| noonedeadpunk | ++ | 17:55 |
| JayF | fungi: we might wanna communicate to projects to accept patches with the DCO signoff if that's the suggested path | 17:55 |
| bauzas | so I guess we need to work on that asap and probably async | 17:55 |
| 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 |
| gmaan | ++, yeah | 17:55 |
| noonedeadpunk | or having it in global git config :) | 17:56 |
| bauzas | (I personally have one week left as I'll take some time-off days before June) | 17:56 |
| 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 |
| 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 |
| bauzas | there are different concerns: one is about the workflow change, the other is company policy | 17:56 |
| 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 |
| JayF | clarkb: that's what I refer to | 17:56 |
| gouthamr | ahh | 17:56 |
| gouthamr | JayF: any examples | 17:57 |
| 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 |
| JayF | I don't remember specifically, it's not the kind of interaction I'd *want* to remember specifics about tbh | 17:57 |
| 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:57 |
| noonedeadpunk | these 2 are different legally | 17:58 |
| gouthamr | https://review.opendev.org/q/message:Signed-off-by+project:%5Eopenstack.* | 17:58 |
| noonedeadpunk | afaik | 17:58 |
| bauzas | I've seen a couple patches already | 17:58 |
| 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 |
| bauzas | with the tag | 17:58 |
| gouthamr | (stephenfin obviously) | 17:58 |
| fungi | (and only unyil we're ready for the dco switch) | 17:58 |
| noonedeadpunk | so if the policy is - what is not explicitly allowed is prohibited - you will get blocked | 17:58 |
| noonedeadpunk | yes, right | 17:58 |
| noonedeadpunk | it might be best option tbh | 17:59 |
| bauzas | that would be *the less worst* | 17:59 |
| noonedeadpunk | we jsut don't know if it's possible, so need to prepare to the worst one | 17:59 |
| gouthamr | time check | 17:59 |
| 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 |
| gmaan | blocked you mean especially from company policy checks/time they need? | 18:00 |
| gmaan | bcz from developer action to correct the commit is easy one | 18:00 |
| bauzas | that would certainly need some proper onboarding period | 18:01 |
| bauzas | even for devs | 18:01 |
| 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 |
| 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 |
| gouthamr | so please don't let meetbot's messages interrupt you | 18:01 |
| gouthamr | thank you all for attending today's meeting | 18:01 |
| gouthamr | #endmeeting | 18:02 |
| opendevmeet | Meeting ended Tue May 20 18:02:06 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-20-17.00.html | 18:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-20-17.00.txt | 18:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-20-17.00.log.html | 18:02 |
| mnasiadka | I don't think anyone is saying it's going to be a problem, we rather need a mechanism to inform them of the changes - because every org has a different process of adapting to that change (internally) | 18:03 |
| JayF | TBH I'm a little worried it'll make us look like we don't know what were doing, from a governance perspective, to do a change this major with that small amount of notice or debate. | 18:04 |
| JayF | We have a lot of governance infrastructure we ask folks to buy into and volunteer time for; it'll look like a failure of that infrastructure to make this big of a change in short notice. | 18:04 |
| JayF | (to be clear: I love the change; I've wanted this forever; but for a project that maintains API contracts forever; we're breaking a contributor API with <2 weeks notice) | 18:05 |
| mnasiadka | Well, <2 weeks notice is not enough, surely - unless we can just accept old CLA/ICLA (for some reasonable amount of time) and require DCO only for new contributors | 18:07 |
| gouthamr | -1 on that thought, i don't think two weeks is short notice for individual developers.. most will shrug this off and do it in a second.. we should worry specifically about the legal implications grey area.. | 18:07 |
| JayF | We're not individual developers. This isn't a hobbyist project. Most of us contribute for pay, and have requisite downstream policies we have to follow while doing it. | 18:08 |
| fungi | the other plan to replace the old icla only for new contributors would also be basically no worse than today, because the process is still effectively the same for them (new user has to agree to a cla anyway, and will agree to the one they're told to, which will be the one for the new org) | 18:08 |
| gmaan | mixing CLA is more problem and confusing then single shot transition | 18:08 |
| bauzas | gouthamr: my concerns are about people not around and back on June | 18:09 |
| bauzas | that and indeed the company legal implications of a contractual change | 18:09 |
| gouthamr | bauzas: i don't think its a problem, they'll see that gerrit just rejected their change, panic and then read the communication | 18:09 |
| gouthamr | legal yes | 18:10 |
| gmaan | bauzas: that is valid and for many part time contributors who are not so frequent contributors to community. | 18:10 |
| fungi | we need to double-check what the error message from git-review looks like, but i'm hoping it's fairly clear and when a user gets it they'll know to just `commit --amend -s` and retry | 18:10 |
| gouthamr | ^ +! | 18:10 |
| gouthamr | ^ +1 | 18:10 |
| JayF | That kinda limited-frequency contributors are the people most likely to be burned by this; openstack-focused contributors are going to get their policy fixed :D | 18:10 |
| bauzas | gouthamr: as gmaan said, we're now all full-time contributors | 18:10 |
| JayF | fungi: it's really, really clear if you implement it anywhere similarly to the branch protections on gentoo | 18:10 |
| bauzas | and we know a fraction of our community doesn't read emails | 18:10 |
| gmaan | we need to communicate it more than ML/resolution. maybe be via PTL/project leaders in their IRC/meetings | 18:11 |
| bauzas | which is still a fraction of our community | 18:11 |
| gouthamr | fungi: you'd enforce this with gerrit's submit-requirements plugin, yeah? | 18:12 |
| fungi | no, gerrit's dco enforcement option | 18:12 |
| mnasiadka | There are always people that don't read emails and don't attend meetings, I don't think we have a way to get that message to them in another way that dco enforcement on submit (and updates in contributor documentation - but they probably don't read that as well) | 18:13 |
| * bauzas remembers old days of OpenStack Upstream Trainings at Summits and how difficult it already was to explain about the CLA | 18:14 | |
| gmaan | something they will ready if they are submitting changes :) | 18:14 |
| fungi | we would switch from https://review.opendev.org/Documentation/config-project-config.html#receive.requireContributorAgreement to https://review.opendev.org/Documentation/config-project-config.html#receive.requireSignedOffBy | 18:14 |
| bauzas | surely a gerrit enforced DCO would give them a shorter and easier to identify answer which is "I need to do something" than the current "I need to accept the ICLA" situation | 18:14 |
| mnasiadka | +1 | 18:15 |
| bauzas | but again, don't forget the companies legal aspect, our contributors would be afraid of signing-off a DCO without getting a blessing from their employer | 18:15 |
| JayF | ++ Yeah, I think the single dev experience is the easy case. My only logistical concern at all is around restrictive OSS policies, and limited-time contributors having that limited-time eaten up filing tickets against LEGAL in jira at $corp :D | 18:15 |
| bauzas | jinxed | 18:16 |
| JayF | When bauzas and I agree so clearly, you know you're in trouble :D | 18:16 |
| JayF | lol | 18:16 |
| bauzas | we have Foundation members, that would be a first start | 18:16 |
| gouthamr | fungi: "Sign-off is a line at the end of the commit message which certifies who is the author of the commit." -- so this would fail if its not alongside Change-Id - i.e., in the last paragraph | 18:16 |
| clarkb | I think you get a message like "not Signed-off-by author/committer/uploader in message footer" after looking at the gerrit code | 18:16 |
| clarkb | in the rejection message | 18:16 |
| fungi | i think the gerrit documentation just has a typo, it enforces the presence of "Signed-off-by" rather than "Sign-off" | 18:17 |
| JayF | oh interesting, so this will have a change then for taking over patches | 18:17 |
| JayF | because we'll have to add an additional signoff | 18:17 |
| JayF | that's a nice little side effect | 18:17 |
| gouthamr | yes! | 18:18 |
| gouthamr | and gerrit UI edits must also somehow do this? | 18:18 |
| fungi | yes, the committer will need to add signed-off-by for themselves, it's typical to see that in other dco-using projects already | 18:18 |
| JayF | ++ it's that way in Gentoo for sure, if I land someone elses patch it needs their+my DCO | 18:19 |
| bauzas | clarkb: fungi: tbc, only the commit msg header would be sufficient ? no need to accept the DCO somewhere else ? | 18:19 |
| fungi | footer, not header | 18:20 |
| JayF | DCO is signed everytime you do Signed-Off-By on a commit | 18:20 |
| JayF | there's no separate document or action | 18:20 |
| clarkb | bauzas: right the way the DCO works typically is a project would have the DCO listed somewhere prominently then say when you sign off by in your commits you are agreeing to the DCO | 18:20 |
| JayF | other than theoretically actually reading what the DCO says and mentally going "yep" before you signoff :) | 18:20 |
| clarkb | and then commonly signed off by is tied to the DCO so that shouldnt' surprise anyone (but I think it is intentionalyl more vague so that you could use it to indicate something else) | 18:21 |
| fungi | when the original tc resolution was approved, markmc added this in the wiki: https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin | 18:21 |
| bauzas | clarkb: the DCO would be staying somewhere in the project's repo . | 18:21 |
| bauzas | ? | 18:21 |
| fungi | er, wrong link | 18:21 |
| JayF | oh, that's a REALLY good point bauzas | 18:21 |
| clarkb | bauzas: it would go somewhere. Maybe in the openstack contributor docs | 18:22 |
| clarkb | possibly in each repo. I don't know exactly where | 18:22 |
| JayF | Ideally it'd be referenced in readme in each repo | 18:22 |
| bauzas | don't we need each repo to communicate about that ? | 18:22 |
| JayF | but that need not be a flag day thing | 18:22 |
| bauzas | either thru a pointer or something else ? | 18:22 |
| JayF | bauzas: that actually make a lot of sense to me, becaues if gerrit tells you "do a signed-off-by", you don't know/read DCO, have you agreed to anything? | 18:22 |
| clarkb | https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin this appears to be where the kernel puts it | 18:23 |
| bauzas | I'm indeed curious about the contract I'm about to sign off | 18:23 |
| fungi | https://wiki.openstack.org/wiki/OpenStackAndItsCLA#The_Developer_Certificate_of_Origin was the url i meant to paste | 18:24 |
| bauzas | I can give a blank check because I trust the OIF but some people may want better explanations | 18:24 |
| gmaan | I think we do not need all project readme instead we need to update this which is pointed from the project contributor doc | 18:24 |
| gmaan | https://docs.openstack.org/contributors/common/setup-gerrit.html#individual-contributor-license-agreement-icla | 18:24 |
| clarkb | https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst that lives in there but is not in the readme | 18:24 |
| gmaan | project side we have this doc linked https://docs.openstack.org/nova/latest/contributor/contributing.html | 18:24 |
| bauzas | yup | 18:24 |
| bauzas | I was thinking about the repo implications | 18:25 |
| bauzas | but the contrib guide should save us :) | 18:25 |
| fungi | oh, actually fontana added most of that wiki article, markmc just made some edits here and there | 18:26 |
| gmaan | I do not think we need to state that at repo level. any openstack contributors should start from what contrib guide has which is applicable for OpenStack as community /for all repo under openstack | 18:26 |
| bauzas | that still leaves 10 days to file a patch to modify the contrib guide :) | 18:26 |
| bauzas | gmaan: yup, agreed | 18:26 |
| bauzas | I was afraid of any repo change but shouldn't be needed | 18:27 |
| JayF | Starting at the OpenStack contrib guide is def. not true in practice for most Ironic contributors, but we do link to it in places. I also suspect we're a bit of a snowflake in that we probably get more unique (e.g. not contributing to rest of openstack) contributors than most other openstack repos | 18:27 |
| gmaan | yeah, that is doable but main is when TC approve it officially so you can -7 days from today (if it need resolution to merge) | 18:27 |
| JayF | So I'd suggest that Ironic add something; but I do think contributor guide is good enough from a "CYA" standpoint | 18:27 |
| bauzas | ah fun, I don't have any CCLA listed in my Gerrit Agreements :) | 18:28 |
| clarkb | bauzas: the ccla is not tracked in gerrit (never was) | 18:28 |
| clarkb | the icla operates as a proxy for the backend ccla management | 18:28 |
| bauzas | sad I am | 18:28 |
| fungi | yeah, the ccla is handled manually by foundation executive management and various contributor company lawyers | 18:28 |
| bauzas | I was considering my 10-year experience of OpenStack as a personal IP :) | 18:29 |
| fungi | ther eis no public record, nor even a publicly-available copy of the ccla text | 18:29 |
| bauzas | and we expect such company-level agreements to be achieved in the next 10 days ? :) | 18:29 |
| fungi | i suspect, but do not know for certain, that there may even be variations in the text of cclas for different companies | 18:30 |
| clarkb | I'm not a lawyer but my understanding here is the DCO is a much much lower bar and it is one that is quite common | 18:30 |
| fungi | bauzas: there will be no ccla going forward | 18:30 |
| clarkb | so it isn't far fetched to think that most companies contributing would already be comfortable with the DCO and it should make contributing by individuals much easier | 18:30 |
| clarkb | overall this should work out better than requiring some form of cla for everyone | 18:30 |
| fungi | the plan, as it was presented anyway, is that the dco would replace the ccla+icla/usgcla documents | 18:31 |
| bauzas | clarkb: because OpenStack DCO = Linux DCO ? | 18:31 |
| bauzas | I mean the kernel one | 18:31 |
| clarkb | bauzas: yes my understanding is we would use the same DCO | 18:31 |
| bauzas | I see | 18:31 |
| clarkb | the DCO originated with the linux kernel iirc, but now is regularly reused | 18:32 |
| clarkb | https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin | 18:32 |
| fungi | https://developercertificate.org/ is "the" dco afaik | 18:32 |
| bauzas | gotcha, yeah, it's versioned | 18:32 |
| bauzas | DCO 1.1 | 18:33 |
| bauzas | stupid question but does the current DCO match our current resolution about AI contributions ? | 18:34 |
| fungi | in what way? | 18:34 |
| fungi | in what way are you thinking it might not match, i mean? | 18:34 |
| gmaan | I think that is separate addition declaration for AI helped contribution. DCO is anyways a separate agreement for any contriobution | 18:35 |
| jrosser | I need to be able to give a url to the lawyer that explains everything going on here in a way that looks official and like an openstack policy doc | 18:35 |
| jrosser | I can’t start any approval for contributions under a new arrangement until that exists | 18:36 |
| fungi | bauzas: i guess it's a philosophical question of whether using a tool (whether it's vim or chatgpt) to compose a contribution means that it was "created in whole or in part by me"? | 18:36 |
| fungi | jrosser: so making sure the right details get incorporated into the tc resolution, you're saying? | 18:37 |
| bauzas | fungi: nothing specific in mind, I was wondering all the implications | 18:37 |
| bauzas | and I have no context yet about the current state we have (can't find the links yet) so I'll need to do some homework before continuing about that open thought | 18:38 |
| jrosser | I’m just saying without anything concrete to put in front of a lawyer people like me can’t even start getting an approval - and I would hope that contributor docs explaining the situation would be available for someone (like the lawyer) who has no context at all about openstack | 18:38 |
| gmaan | The key things/time is when resolution will be merged? until then, it is difficult for anyone to present it to downstream for approval. | 18:38 |
| bauzas | ah, found it https://openinfra.org/legal/ai-policy | 18:39 |
| bauzas | gmaan: I assume my main concern is about the June 1 timeframe | 18:40 |
| bauzas | and what's changing there | 18:40 |
| fungi | bauzas: my (admittedly not-a-lawyer) read is that if you couldn't contribute something under the dco because of our ai contribution policy, then you wouldn't be able to contribute it under the icla either. the assertions in both are effectively equivalent | 18:40 |
| bauzas | because the worst that I can imagine implies that we're ready to vote a written resolution by the next Tuesday meeting | 18:41 |
| gmaan | I am not much concerned about what changing but yes timeline can be/is a big challenge | 18:41 |
| gmaan | I mean we know what changes will looks like | 18:41 |
| bauzas | and we would need to modify a substantial portion of our docs meanwhile | 18:41 |
| gmaan | true | 18:41 |
| gmaan | and communication, because it will be issue if anyone just see their changes blocked next morning without any prior communication/discussion | 18:42 |
| gmaan | it will be better, if we can float the discussion (formal approval) at least a week before | 18:43 |
| gouthamr | i can take a stab at the resolution | 18:47 |
| gouthamr | lets put through formal review on gerrit and gather any thoughts on the change and the ML | 18:48 |
| fungi | correcting my earlier statement, it looks like these days the ccla text is actually anonymously viewable by following the echosign link at https://openinfra.org/cla/ (not sure when that changed) | 18:48 |
| fungi | also i just heard that the foundation has not made exceptions for company-specific variances in the ccla text, to my surprise | 18:49 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: [resolution] Replace CLA with DCO for all contributions https://review.opendev.org/c/openstack/governance/+/950463 | 20:41 |
| gouthamr | tc-members: please pitch-fork this.. ^ | 20:42 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Clarify actions when no elections are required https://review.opendev.org/c/openstack/governance/+/949431 | 21:55 |
| opendevreview | Merged openstack/governance master: fix prettytable deprecation warning https://review.opendev.org/c/openstack/governance/+/948825 | 22:03 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!