4.x Release plans

[andrewgsavage]

Most of the topics in #201 are completed so I'm starting this for the next release, which I presume will be 4.0.0

Skimming through the previous topic and development plans, it looks like the following weren't resolved and could be in the next release:

• Linting, precommit
• Renaming/aliasing of UFloat, AffineScalarFunc

I've been working on:

• Some reorganisation into smaller files Reorganise core #187
• improved numpy support (https://github.com/andrewgsavage/uncertainties/tree/numpy will submit a PR after Reorganise core #187 is merged)

Is there anything else you'd like to see in a 4.0.0 release?

[newville]

@andrewgsavage This all sounds great to me. I would still like to have something done about the self-referential
LinearCombination thing of:

class Variable(AffineScalarFunc):
     __slots__ = ('_std_dev', 'tag')
    def __init__(self, value, std_dev, tag=None):
        value = float(value)
        super(Variable, self).__init__(value, LinearCombination({self: 1.}))

with the lengthy discussion at #218 (somewhat noisy, as we are still coming to grips with what this means).

I think the simplest solution might be to replace LinearCombination({self: 1.}) with LinearCombination({None: 1.}) and then have AffineScalerFunc pass in its own self to LinearCombination.expand()as the "value to use in place ofself". I think that will make Variablebe easier to serialize, and not need the wholeid` business. I suppose that means I just volunteered to make a PR...

[wshanks]

I would be opposed to making std_dev un-settable (n and nominal_value are).

For what reason do you oppose making std_dev un-settable like nominal_value? Is it to preserve the feature of being able to modify an independent variable's uncertainty and calculate the new uncertainty for a dependent AffineScalarFunc? Or to keep backwards compatibility?

I would also be okay with #219 or something like it if we could add a warning to std_dev.setter of Variable that, if the user tried to change the value to or from 0, would complain that previous tests of equality and hashing might no longer be valid. That was the main issue for me -- a hash should never change and items that hash to the same value need to be equal, but changing a finite std_dev to 0 would make an AffineScalarFunc equal to a float with the same nominal value. Tweaking the value in any other way should be fine and with that warning the user could even set the value to 0 knowing they should try to use it as a dict key afterwards.

[newville]

@wshanks Very sorry, my mistake. I would NOT be opposed to making std_dev an un-settable property, just as n and nominal_value are unsettable. I do worry a bit that making _std_dev and _nomimal_value static might make implementation more complicated -- perhaps making these __std_dev__ etc would make them more obviously "private".

[jagerber48]

@newville @wshanks See #251

[andrewgsavage]

I have a hunch that core is architecture the way it is to support a late-evaluation of chains of dependencies between variables with uncertainty in a way that allegedly improves performance. I haven't seen any performance data anywhere, it's just a hunch I have based on the comments.

I think it would be worth seeing either trying an instant evaluation or using a covariance matrix and seeing how much slower it would be to understand the performance cost of a simpler implementation

[jagerber48]

@andrewgsavage after re-implementing the "linear combination of uncertainty atoms" and finally understanding how it works, I less have the feeling that it is unintuitive compared to a covariance matrix approach. And I think it's a bit nicer programmatically because there isn't shared information between different objects. In the linear-combination-of-uncertainty-atoms approach each variable keeps track of the atoms it depends on. Then when two variables come in contact their local atoms are compared.

In the covariance matrix approach there is a sort of global state that needs to be kept track of which variables exist and how are they correlated. There could be one huge covariance matrix that keeps track of all variables, but I think this would quickly become untenable if large calculations are done. One could imagine only storing the covariance between variables X and Y locally on those objects, but this would need to be synchronized, and, depending on the connectivity of calculations, we could also end up with huge covariance matrices.

In the linear combination of atomic uncertainties we write X = X_0 + dX, Y = Y_0 + dY Z = X + Y = (X_0 + Y_0) + (dX + dY). In the covariance approach we think of only Z = X+Y` but retain memory of the covariances between X, Y, and Z.

I have ideas how this can be more clearly documented.

---

However, you also mentioned testing early vs. late evaluation. I do think early evaluation could simplify the implementation, so I agree that this would be interesting.

[newville]

@andrewgsavage @wshanks @jagerber48 But also: is it OK if we view #245 as something we should merge now and then push out version 3.2.2 for Numpy2 compatibility, and then switch to more refactoring for 4.0?

[wshanks]

That sounds good to me!

[andrewgsavage]

Yes please, numpy2 support warrants a release as soon as it's ready

[wshanks]

One thing I think would be good to tackle for a 4.x release is the numpy.matrix deprecation warning (#114). I think the reason numpy wants to deprecate numpy.matrix is that the main motivation for it was so that * could be overloaded as matrix multiplication, but after pep425 added the @ symbol for matrix multiplication that motivation went away and it has just been a very slow deprecation in numpy as it waits for scipy, etc. to stop using numpy.matrix (it passed on the opportunity to complete the deprecation with numpy 2.0).

The problem for Uncertainties is that we have umatrix which uses numpy.matrix. We should figure out if we want to keep or deprecate umatrix. We could switch to keep the current umatrix interface without using numpy.matrix or we could deprecate it and just keep the inverse function and let users call that on a plain uarray when necessary. I think the inverse function is the main value added by umatrix. We don't need to make many changes for 4.0, but I think it would be good to add a deprecation warning on umatrix with that release if that is the direction we want to go.

[newville]

@wshanks I agree. Numpy encourages abandoning matrix. We should listen to them. I am +1 on deprecating umatrix either now or with 4.0, and hopefully removing it in a year or so.

[jagerber48]

I am +1 on getting rid of umatrix. Right now #262 doesn't fully support umatrix. Right now #262 mostly acts as if np.matrix doesn't exist. If necessary, I can modify it so that it checks if inputs are matrices and, if so, it will recast them to matrices during derivative calculation and at the output. At least supporting inv and pinv in this way should be not too hard to do.

I would love if we could just drop umatrix at 4.0 but maybe that is unfair to users and we must deprecate it for some time before entirely dropping that? Basically the question is should I put in the work to make sure #262 supports umatrix at the level it is currently supported?

[jagerber48]

I want to ask here about timing for switching to sciform as a formatting backend. My suspicion is that, if this change is approved, it will likely come with at least some changed formatting behaviors, and possibly some breaking changes to the format specification mini language. If that it is the case I would say it is likely we would want sciform to be added at a major version change.

However, I fear this change will not be ready for 4.0 just given timings of everything. When/if #262 is completed I think it won't be long before we can knock out some smaller tasks to be ready to release 4.0. The question is, would we want to wait for the possible sciform code changes and discussions to go through for 4.0 or not? If not, is there a chance for sciform to come in in a later version? 4.x or 5.0? What I'm wondering is if 4.0 is the last ship that sciform can sail in on and I should try hard to get it in, or if I can wait and do sciform on whatever timeline is "comfortable" for myself and others.

Also apology to folks for the huge flurry of activity from myself on JUST TODAY. this happened to be a day that a lot of my work coalesced and I was able to spend some time on github. Please respond at your leisure.

[jagerber48]

@lebigot @newville @andrewgsavage @wshanks

Ok, here is the plan for getting from here, 3.2.2 to 4.0.0. The release of 4.0.0 centers around PR #262 which involves a re-architecture of the main UFloat class and changes some API functionality.

1. Merge Refactor power derivative functions #294, Mark comparison operations as deprecated #299 and Raise a warning for std_dev==0 #300 into master.
2. Create a PR to resolve Get doctests to pass #281 and get it merged into master. [This PR was created: Fix doctests #301] 4.0.0 will be a pretty large change and will also have a bit of changes to the documentation. It will be valuable to have doctests passing before and after that change.
3. Release master as version 3.2.3. I propose a patch version bump since there are no actual behavior changes except a minor bug fix. (Many of the changes are on the developer rather than user side).
4. Create a release branch off of master called rel_4.0.0.
5. Create and merge PRs into that rel_4.0.0 branch which:
   5a. Implement the deprecation on some UFloat methods and uncertainties.umath methods. I.e. delete those methods/functions.
   5b. Simplify the code that implements isnan and isinf. This will remove many lines of code from ops.py, It's not worth it to make this change until __trunc__, __floor__ and __ceil__ are removed, but it may be worth it to have this change before Eliminate the Variable class #262 is merged.
   5c. Remove testing for std_dev==0
6. Complete work on Eliminate the Variable class #262 and merge it into rel_4.0.0. The remaining work I see:
   6a. The changes/removals above will allow some simplifications in Eliminate the Variable class #262. It will be good to take these
   6b. Eliminate the Variable class #262 will implement a resolution to Problem with special casing std_dev = 0 #283 by stopping special casing std_dev==0 during uncertainty propagation
   6c. A fair deal of documentation cleanup will come in this PR. The documentation changes involve emphasizing that UFloat models a random variable and reworking some of the sections that rely on the to-be-removed derivative concept.
   6d. Right now Eliminate the Variable class #262 slightly degrades performance as measured by the codspeed.io metric. The linear complexity is mainted, but the prefactor is degraded by a factor (maybe 2x? I forget how bad it is). We either need to resolve this performance degradation or decide that it is acceptable and move on. Once we get to this point in the checklist I plan to dive into this a bit.
7. There should be specific documentation that appear on the docs webpage, not just the CHANGES.rst file, explaining what breaks in moving to 4.0.0.
8. Final checks on the rel_4.0.0 branch. Changelog etc.
9. Merge rel_4.0.0 into master and release master as version 4.0.0.

The reason for the rel_4.0.0 branch is that I don't want the release of 4.0.0 to block any smaller or urgent that should happen on 3.x.y in the meantime.

---

Thoughts on this proposal? My next step is getting the doctests PR going since getting through that will take some time.

One question: The UFloat.derivatives property will be going away in 4.0.0. Do we want to add a deprecation warning for it now? The problem is that in 4.0.0 it's functionality will be kind of replaced by error_components which exists now, and which will exist in 4.0.0, however the behavior in 4.0.0 will be different because the keys will be UAtom objects, not Variable objects. So I'm not sure that the deprecation warning will actually help users that much.

[jagerber48]

Also, how long do we want to stay on 3.2.3 before moving to 4.0.0? If 4.0.0 is ready two weeks later do we release it? Or do we want to give users more chance to see the deprecation warnings?

[jagerber48]

Excellent, the PRs for 3.2.3 are all in. Thanks all for the help getting those through! I or someone can make a 3.2.3 release branch that just tidies up the changelog. We can PR merge it and then create a new release.

Then, I think the next step will be to create the rel_4.0.0 branch. I will try to push that to the lmfit fork rather than my personal fork, then, I think, we can implement the major changes in that branch as a sequence of PRs. E.g. PRs implementing 5a-5c from the list above. I think #262 will be closed and re-opened as a PR into the rel_4.0.0 branch. That PR will cover all of 6 and will be the relatively big PR.

As I've said above, most of the code is in place for the big PR minus some improvements that can come due to the recent changes and minus an exploration into the performance. But I think it will be a bit of time going through the documentation making it consistent with the new changes, philosophy, and shining it up a little.

[newville]

@jagerber48 Sounds good to me. I am in favor of you making a 3.2.3 release branch ;).

After that, we could just treat the master branch as "4 development", but making a separate branch would be OK too.

Maybe that is a good opportunity to change the primary branch to be named "main", for those of us old enough to remember when "politically incorrect" was viewed as a negative trait.

[jagerber48]

Maybe that is a good opportunity to change the primary branch to be named "main", for those of us old enough to remember when "politically incorrect" was viewed as a negative trait.

Ah, that's a slick hack. We can do that. Will require some github repo reconfiguration maybe but that's no problem. Yeah the reason for the extra "4 development" branch was just a hedge against us some change coming up that we wanted to sneak into 3.x. but either way there are ways to do that. The master -> main jump gets two birds with one stone though.

[newville]

I think you can just make a branch named "main" and then change that to the "default" branch. But it is nice to tie that to a clear transition like a release.

[jagerber48]

I'm starting some work on the main branch.

• I removed the requirement for all commits to this branch to be via pull request
• I removed the requirement for this branch to be linear (I can push merge commits).

Removing these guards is allowing me to just work quicker on that branch rather than requiring agreement from other maintainers. For example keeping this branch on track with master until we release 4.0.0 and main supersedes master. At that time these guardrails will be put back in place.

Should I just make all my changes "freely" on this branch? Or should the more substantial changes (listed in steps 5 and 6 above) be done via PR? @newville @wshanks @andrewgsavage? For example should #309 go through the proper approval/PR process or can I just merge this and similar change myself? And then the team will review all the changes together before we release 4.0.0? My initial motivation for making steps 5 and 6 through PR was so that the changes come in smaller chunks rather than one huge diff for the final release.

[jagerber48]

I lean towards having the changes go through PR. The changes might be small in the source code but they may be large in the tests. This will cause the changes to go through much more slowly but I think it will be worth it so that people can see the changes as they come and to have the history come in more bite size chunks..

Another option is I can make the changes via PR so that the chunks are there, but I can self-approve and self-merge the PRs. Opinions?

[newville]

@jagerber48 I agree. Treat 'main' as a development branch until we make it replace 'master' as the master/main/primary/production branch.

Don't be held back by approvals or trying to keep things linear. Don't worry about making a mess.

[wshanks]

If you can make PRs and squash merge them, I think that makes for a more readable history, which can be helpful for others looking at the code later and trying to understand how it came to be the way it is. I am okay with whatever works best for you though. Merging without approval seems okay. You can still highlight and ask for approvals on a subset of PRs.

[jagerber48]

Status update 2025/06/08

@newville @andrewgsavage @wshanks

There are three branches of interest now, master, main, and feature/linear_combo_refactor. there is also the currently released 3.2.3 tag.

• master is now a number of commits ahead of 3.2.3. I think we should probably release 3.2.4 soon, that will slightly clean things up. I'm not sure what should happen to master after we release 4.0 from main. My recommendation would be to delete that branch rather than try to, e.g., merge main into master and continue to keep master around. Of course we'll need to make configuration changes in github and possibly readthedocs, codecov, and codspeed (though I think github might be enough).
• main consists of all the breaking changes between 3.x and 4.x which are NOT being handled in linear_combo_refactor. Mainly this includes the removal of functions and methods that have been marked as deprecated in 3.2.3 and which will be marked as deprecated when we release 3.2.4.
• feature/linear_combo_refactor is still a big branch. There is good progress on it but the 20% performance regression (Refactor Speed Benchmarking #327) and documentation are still outstanding. I am going through the whole documentation making sure it is up to date with the refactor but also some of our modern understanding of the code and doctests etc. This is a big task. When this PR is ready I will let people know and request a review for the merge from feature/linear_combo_refactor into main. When we do that we should also be ready to make a release of 4.0.0 from the main branch.

There are two changelog sections. One which will become the newest 3.2.4 entry when we make that release. This changelog section appears on all 3 branches. Another section which will be the 4.0.0 entry which appears on main and feature/linear_combo_refactor.

The feature/linear_combo_refactor -> main PR is going to be big, but I've broken it down as much as I think I really can. I take some looks over to see if there are any more reductions I can make (e.g. by making changes in master or main. But I think that is going to be the nature of this sort of architecture change. We should discuss in detail when the PR is ready for review.

One question I had for @lebigot Would you like to have a chance at a review of the new code before we release 4.0? Or if us other maintainers are happy with it are you happy for us to move forward with the release? I wanted to ask you since this is probably the biggest change the codebase has seen in years and it is hopefully the last change of this scale it will see ever, or at least in a very very long time. I don't think anyone is in any rush to get this release out. I probably drive the main pressure because (1) I'm excited about the new code and (2) as much as I enjoy working on this, I will be happy to focus on other projects a bit after this release.

[lebigot]

Thank you for asking, @jagerber48! I don't need to review the new code: in my mind, the whole codebase is now in your hands, and @newville's, @andrewgsavage's and @wshanks'.

I am looking forward to the 4.0 release.

Good luck with everything!

[jagerber48]

@newville @wshanks @andrewgsavage
I've been very busy lately so haven't had time to push forward on uncertainties. Thanks all for your patience.

The comment I'm responding to was originally posted here by @newville, but I want the discussion to happen in this discussion thread instead. #330 (comment)

@jagerber48 @wshanks Yes, reviewing for 4.0.0 will be challenging. For me, at least ;)

I would suggest a few things (maybe not all are needed):

• a plan to do 4.0.0rc1 and rc2, that would allow docstring, doc, and example changes, and fixes to match expected behavior.
• clarifying that "4.0.0" will be a very big change, and deciding if we also release (and promise to support for a while) a 3.2.4 (or 3.2.FINAL) around the same time.
• A Zoom meeting with several of us to get us up to speed on the design might be helpful to allow more meaningful reviews.

Thank you for these suggestions @newville they're very helpful.

---

As a reminder here is what I see remaining in terms of source code changes before we release 4.0.0

• Address (or not) the performance reduction Refactor Speed Benchmarking #327
• Additional passes (by me) over the source code, source code diff, and documentation
• Large cleanup of docs and source code throughout the codebase Clean up docstrings and comments throughout the source code and tests #330.

Also a reminder that there are a few changes collected in master ahead of the latest release, 3.2.3.

---

1. I'm not totally sure from a git mechanics perspective how 4.0.0rc1 and 4.0.0rc2 would work. My guess is we would create a branch at the tip of feature/linear_combo_refactor named 4.0.0rc1 and I would make minor source code changes and performance improvements there. Then we would branch 4.0.0rc2 off of 4.0.0rc1 and I and others would work on cleaning up the extensive comments on that branch. Then I guess we would merge 4.0.0rc1 into main after a PR and review and then we would merge 4.0.0rc2 into main after PR and review and then finally we would make a github release of main as the final step (triggering a pypi and readthedocs release of the new version). This double release candidate approach seems good to me. It would separate out the two diffs, each of which will be very large on its own.
2. Yes, I haven't put anything in the docs yet advertising the 4.0.0 change. We should probably support 3.FINAL for a bit, would 6 months be reasonable? Maybe 18 months if some major undiscovered issue is found (seems unlikely but I guess you never know)?I would like to just encourage folks to migrate to 4.x at that point, but since there are a few breaking changes maybe someone will have a case where they prefer <4.x for some reason? We can put something like this in the next 3.2 release.
3. When I first read the zoom meeting idea it shocked me! I hadn't thought of that. But I think that is actually an excellent idea. Trying to communicate the large number of changes and nuances over asynchronous text has been challenging. I hope a zoom meeting would give everyone the bump needed to be able to review "4.0.0rc1".

---

Here are my proposed action items

• Put notes in the online documentation advertising the big change to 4.x is coming. I'll take a draft and make a PR about what to include here. I think a sneak peak at the change log (meaning a paraphrased version of the biggest changes) and a description of the migration process and our support plan for <4.0 and >= 4.0 are the highlights.
• After those notes are in I think we're ready to release 3.2.4. We should do that to clear the space if we can. We should double check that all the important deprecations are marked. And now that I say that I recall that, e.g. I haven't marked AffineScalarFunc.derivative as deprecated. This is the biggest change in "philosophy" but I don't know or not if this method/property is widely used. It's certainly cited heavily in the docs.
• Next I'll take a pass or two through the 4.0.0 diff to remind myself where the code is at and to prepare for a meeting. On the one hand, I don't want to have the meeting until I think 4.0.0 is ready for review because I don't want to end up in a situation where we have this "big" meeting but then have to wait weeks or something before the code is actually ready to review. On the other hand, maybe we should meet early to free up as much progress as possible and plan on another meeting before the "big" review if needed. Thoughts?
• If my described git mechanics workflow for 4.0.0rc1 and 4.0.0rc2 make sense then I can get those branches going and push them to the lmfit repo.
• After the meeting hopefully the review process can kick off and we can eventually merge into main and make the releasese.

[newville]

@jagerber48 Thanks -- and no worries about taking a break from this!

I think this looks good. If I read this correctly (but with not a lot of confidence, so please correct if wrong), the order could be:

1. add "version 4 is coming" to the docs and deprecations to the code.
2. tag and release 3.2.4 from master with not too many changes beyond "current master" and "added information about 4".
3. merge linear_combo_refactor (into master or main?) and maybe tag this as 3.2.final. I am not 100% clear on whether this or 3.2.4 should be "long-term support". Either is fine. I think "long-term support" means 1 or 2 years.
4. you tag main as 4.0.0.a1 when you think it is ready for first review. Maybe we have 4.0.0.a2 or go to 4.0.0.b1 at which time we're ready for ...
5. have a Zoom meeting. I don't think this needs to be "big" and I don't think it needs to be "one and done". But that probably gets us most of the way to identifying any changes that might be needed to ...
6. tagging 4.0.0.rc1. That should really mean "API done for 4.0.0", so inviting downstream packages to test and fixing docs and examples. FWIW, I'll be testing lmfit with 4.0.0.a1. Maybe there needs to be an rc2, or maybe external testing is all fine.
7. release 4.0.0. In spite the above steps, many people will view (N+1).0.0 as "alpha, new API, could break all my code". So, patience is needed and 4.0.1 should be "in the back pocket" (maybe even identified during the rc phase). Getting to (N+1).0.2 or so demonstrates that the project is active and serious about fixing newly discovered downstream bugs.

Realistically, it would be completely reasonable for each of those steps to take about a month.

[jagerber48]

Status Update 2025/09/09

---

It's been some time since I've looked at uncertainties, so I'm getting myself back up to speed on this release. We are still in line with the plan laid out in the 2025/06/08 status update. Let's keep this update bit sized and focused on the <4.0 work that needs to happen. We want to get 3.2.4 released.

• Once deprecate derivatives and error_components #337 and Release announcement #339 are merged into master we are ready to release 3.2.4 I suppose Update testing for Python 3.14 #341 slips into this list as well now.
• Regarding the future of 3.x branches:
  • We will continue to support (i.e. provide bugfixes) for 3.x for 1-2 years after the release of 4.0.
  • I don't see a need for special tagging of a 3.2.final tag or release. As we saw with Test failure with Python 3.14: tests/test_umath.py::test_math_module - AssertionError: assert ('expected a positive input',) == ('expected a ...ut, got 0.0',) #340, surprisingly little issues may crop up and push us to 3.2.5, 3.2.6 etc. before finally dropping support for 3.x so I don't really see the point in a special tag here.

[jagerber48]

Status Update 2025/012/23

@lebigot @wshanks @andrewgsavage

---

Not much update rom the 2025/09/09 update. We still need to merge #337 and #339. But I think those are both blocked by #336. We need to come to an agreement on what to do with AffineScalarFunc.error_components() and AffineScalarFunc.derivatives. See #336 for more details and please extend discussion there. I summarize my point of view here:

• We should remove the derivatives property. The architecture change from 3.x to 4.0 basically makes it impossible to report derivatives without major changes.
• My top preference would be to remove the error_components() method entirely. This would also come with removing the tag input to the UFloat constructor and would make UAtom now a private implementation detail. There are downsides to this to be considered and discussed in UFloat.error_components, method or property? derivatives deprecation? #336.
• My next preference would be to keep error_components but change it from a method to a property. In this case we keep the tag kwarg in the UFloat constructor and UAtom now must be a public documented class because it appears as the keys in the error_components dictionary.
• Lowest preference is keep error_components() as a method, keep tag, and keep UAtom public.

Let's make a decision on this in #336 and then we can move forward with those 2 PRs and releasing 3.2.4.

[newville]

I agree: 4.0 should drop derivatives, make error_components a property. Deprecating those now would be good.

[lebigot]

I don't foresee any major problems with removing access to derivatives: for what it's worth I've never seen anybody use this package for this; also, if someone wants to calculate derivatives, they're better off with other packages (like PyTorch).

However, removing access to error components would seriously bother some people: I've seen a few people, notably in metrology, need that for a paper, because they need to document the sources of their final uncertainties. So I also suggest to keep them.

I don't see any issue with making them a property (with a proper early deprecation warning).

[jagerber48]

Status Update 2026/01/09

---

We finally released 3.2.4, closing out a few PRs that required us to agree on what breaking changes we're ok with for releasing 4.0. Now we return work to the 4.0 2025/06/08 was my last update with stuff pertinent to that. I need to dig into to remember details, but I think the rough plan will look like:

• get main back up-to-speed with master. Reminder that main implements some of the simple deprecations like removing certain functions.
• Then we turn attention to feature/linear_combo_refactor. This is the big branch with all the changes. I need to remind myself what is going on there. I think all the features work and tests pass. However, the performance regression is there and a lot of documentation work needs to happen. Documentation includes finishing updated online documentation, making sure there is no old and inaccurate documentation in the source code and generally pruning comments in the source code, instead preferring docstrings and documentation on the website docs.

I think this is the time when it could be good to have an informal zoom call where I can walk folks through what is going on in feature/linear_combo_refactor. Then we can decide how it makes sense to divide and conquer the remaining work.

[newville]

@jagerber48 @wshanks @andrewgsavage @lebigot Thanks - that sounds good. I agree that a Zoom call would be helpful here.

Here's a when-to-meet poll for the rest of January (I know I am booked on the 12th): https://whenisgood.net/zznjwp2
Pushing off to later is OK, too.