Before 2 there is some due diligence required. Maybe the following has been discussed and I missed it, but:
2a. Is this signal processing code Apache License, v2.0? 2b. What is the IP provenance of this signal processing code? Who holds the copyright? 2c. How large is this codebase? Best, Dave > On Aug 5, 2025, at 3:58 PM, Alexander Sorokoumov > <aleksandr.sorokou...@gmail.com> wrote: > > I agree with all 3 statements here :) So, the short-term plan sounds like: > 1. Port Joe's branch to uv. > 2. Copy-paste currently used signal-processing code to Otava. > 3. Finish the upgrade OR find the next issue. > > Best, > Alex > > > > On Tue, Aug 5, 2025 at 2:46 PM Henrik Ingo <hen...@nyrkio.com> wrote: > >> I thought about the signal processing code today and have an opinion: >> - Thiscode really belongs in the same repo, so we should just go ahead and >> add it. I wouldn't even call it vendoring, I expect the division to >> disappear soon after we bring the two halves together. >> - Regarding which version to work with, we should in any case just start >> with the version we consume now (1.5.somethiing?). >> - If we then want to upgrade to the newest version we would do it as a >> stream of separate commits and so that you can follow the changes both to >> Otava code and e-divisive code in the same commit. >> >> When you break it down this way, it turns out we can go ahead and do 1 and >> 2 , and 3 we can discuss with MongoDB perf team when they have time. >> >> henrik >> >> On Tue, Aug 5, 2025 at 8:19 PM Alexander Sorokoumov < >> aleksandr.sorokou...@gmail.com> wrote: >> >>> I agree that updating the Python version is the most pressing sweeping >>> issue that also blocks adoption and the biggest challenge there is >> deciding >>> what to do with signal processing code. I propose to vendor the necessary >>> code from 1.3.5 to a module within Otava today (naturally, with giving >>> credit and referring to the original source code) and discuss >> collaboration >>> modes async when MongoDB folks respond on the other thread. >>> >>> Best, >>> Alex >>> >>> On Tue, Aug 5, 2025 at 5:25 AM Henrik Ingo <hen...@nyrkio.com> wrote: >>> >>>> By the way, now that uv is merged, is there also a plan to jump forward >>> on >>>> python versions? >>>> >>>> More generally what I'm really asking is, do we still have many >>> "sweeping" >>>> changes left. Changes that we may want to get out of the way before >>> opening >>>> up to general hacking on new features and such? >>>> >>>> I guess deciding on the location of the e-divisive / signal processing >>> code >>>> is somewhat sweeping, even if not as much in your face as chaning the >>>> project name or build tool. >>>> >>>> henrik >>>> >>>> On Tue, Aug 5, 2025 at 1:02 PM Henrik Ingo <hen...@nyrkio.com> wrote: >>>> >>>>> First ever public discussion about a technical change in Otava! Feels >>>>> right. >>>>> >>>>> On Tue, Aug 5, 2025 at 6:04 AM Dave Fisher <w...@apache.org> wrote: >>>>> >>>>>> As a mentor I want to give a meta +1 that you had this discussion on >>> the >>>>>> dev list. >>>>>> >>>>>>> On Aug 4, 2025, at 4:18 AM, Lari Hotari <lhot...@apache.org> >> wrote: >>>>>>> >>>>>>> +1 for using uv. >>>>>>> >>>>>>> -Lari >>>>>>> >>>>>>> On Tue, 29 Jul 2025 at 01:28, Alexander Sorokoumov >>>>>>> <aleksandr.sorokou...@gmail.com> wrote: >>>>>>>> >>>>>>>> Hey everyone, >>>>>>>> >>>>>>>> This change is significant, so I wanted to open a discussion >> about >>> it >>>>>> first. >>>>>>>> >>>>>>>> The main motivation for this change has been that the current >>> Poetry >>>>>>>> version does not support later Python versions and newer Poetry >>>>>> versions do >>>>>>>> not support our current project config format. Since the build >>> system >>>>>>>> upgrade requires additional effort, I was wondering if it is time >>> to >>>>>> shop >>>>>>>> for an alternative and did find uv. >>>>>>>> >>>>>>>> In my opinion, uv is a more promising alternative for 2 reasons: >>>>>>>> >>>>>>>> 1. It follows an approach similar to build tools one can find in >>>> other >>>>>>>> ecosystems (looking at Maven/Bazel/Gradle). It is a single >>>> entry-point >>>>>> to >>>>>>>> manage dependencies, python versions, build and upload artifacts, >>>> etc. >>>>>> I >>>>>>>> did not find a way to also run tests and benchmarks without >>>>>> tox/pytest, but >>>>>>>> it is definitely a step in the right direction IMO. >>>>>>>> 2. It is fast. I encourage reviewers to compare how long it takes >>> to >>>>>> sync >>>>>>>> dependencies or re-build a lock file with uv vs Poetry. >>>>>>>> >>>>>>>> I have opened a PR to showcase what the project will look like >>> after >>>>>> this >>>>>>>> change https://github.com/apache/otava/pull/80. >>>>>>>> >>>>>>>> Please let me know what you think. >>>>>>>> >>>>>>>> Best, >>>>>>>> Alex >>>>>> >>>>>> >>>>> >>>>> -- >>>>> *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* >>>>> >>>>> Henrik Ingo, CEO >>>>> hen...@nyrkio.com LinkedIn: >>>>> www.linkedin.com/in/heingo >>>>> +358 40 569 7354 Twitter: >>>>> twitter.com/h_ingo >>>>> >>>> >>>> >>>> -- >>>> *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* >>>> >>>> Henrik Ingo, CEO >>>> hen...@nyrkio.com LinkedIn: >>>> www.linkedin.com/in/heingo >>>> +358 40 569 7354 Twitter: >>>> twitter.com/h_ingo >>>> >>> >> >> >> -- >> *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* >> >> Henrik Ingo, CEO >> hen...@nyrkio.com LinkedIn: >> www.linkedin.com/in/heingo >> +358 40 569 7354 Twitter: >> twitter.com/h_ingo >>
