RLS: 2.1.2

[lithomas1]

scheduled for October 25, after the dev call.

[lithomas1]

@pandas-dev/pandas-core
Are people OK with releasing tomorrow instead of today?
(I wasn't there at the call, but it looks like there a couple of PRs people wanted to get in barely weren't ready today.)

I don't think CI is in a good state either (looks like some timeouts), so the extra day would also help in getting everything back to a nice state there.

[mroeschke]

I'm okay with tomorrow. From the call, #55173 was more strongly wanted to be in for 2.1.2

[WillAyd]

Sure let's take another day. I don't think there is a rush

[rhshadrach]

We're still okay to merge to 2.1.2 then, yea?

[lithomas1]

Yep.

[lithomas1]

@pandas-dev/pandas-core

Closing off the milestone now, and will start release after all backports are in.

Please don't merge to 2.1.x anymore.

[lithomas1]

@pandas-dev/pandas-core

The release process is mostly finished now - feel free to merge to 2.1.x again.
Thanks to everyone that made this possible!

PyPI wheels and docs and docs have been uploaded.
conda-forge packages are currently building, so I'll make the release announcement tomorrow.

While things went mostly smoothly, there are two minor issues with the release:

1. Release note nits

   • The release date is wrong, since it has yesterday's date instead of today.
     Not a huge deal, but I'll try to catch small issues like this in subsequent releases.
   • Also, there seem to be a couple empty bullets that should've been taken out.

2. For some reason the Python 3.10 single CPU tests, segfaulted seemingly after the tests completed.

   This doesn't seem to happen frequently, in fact CI was green on 2.1.x and on PRs when they were merged.

   Here is a log in case someone wants to dig in more:
   https://github.com/pandas-dev/pandas/actions/runs/6658145173/job/18094375297#step:9:467

Also, this is pretty minor, in the future, it'd be best to get everything for a release merged the day before the release.

Unfortunately, our CI is really slow again, so if you merge the day of, I have to wait for CI to finish on the backport PR, and then wait for CI to be green on the release branch, which adds a couple hours to the release time. This would also be helpful for preventing things like the release note typos, since I can proofread them the morning before.

[mroeschke]

Unfortunately, our CI is really slow again, so if you merge the day of, I have to wait for CI to finish on the backport PR, and then wait for CI to be green on the release branch, which adds a couple hours to the release time.

Sorry for contributing to this. I can have a self moratorium to not push/merge during your release time to make things easier.

[WillAyd]

For the segfault this is where I think getting ASAN/UBSAN will help. Running the window tests locally I see the following issue, which I assume is the root cause (there may of course be other issues - these linters stop on the first error):

==710467==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000021c30 at pc 0x7f9a6e0b98ca bp 0x7fffc89f22a0 sp 0x7fffc89f2298
READ of size 8 at 0x602000021c30 thread T0
    #0 0x7efd172b98c9 in __pyx_pf_6pandas_5_libs_6tslibs_12tzconversion_tz_localize_to_utc pandas/_libs/tslibs/tzconversion.cpython-310-x86_64-linux-gnu.so.p/pandas/_libs/tslibs/tzconversion.pyx.c:6616
    #1 0x7efd172ac577 in __pyx_pw_6pandas_5_libs_6tslibs_12tzconversion_1tz_localize_to_utc pandas/_libs/tslibs/tzconversion.cpython-310-x86_64-linux-gnu.so.p/pandas/_libs/tslibs/tzconversion.pyx.c:5102
    #2 0x56267948c515 in cfunction_call /usr/local/src/conda/python-3.10.12/Objects/methodobject.c:543
    #3 0x562679485a6a in _PyObject_MakeTpCall /usr/local/src/conda/python-3.10.12/Objects/call.c:215
   <truncated CPython traceback>

0x602000021c31 is located 0 bytes to the right of 1-byte region [0x602000021c30,0x602000021c31)
allocated by thread T0 here:
    #0 0x7f9adae955f8 in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x7f9ad6fa109e in PyDataMem_UserNEW (/home/willayd/mambaforge/envs/pandas-dev/lib/python3.10/site-packages/numpy/core/_multiarray_umath.cpython-310-x86_64-linux-gnu.so+0x1a109e)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/willayd/clones/pandas/build/cp310/pandas/_libs/tslibs/tzconversion.cpython-310-x86_64-linux-gnu.so+0xb98c9) in __pyx_pf_6pandas_5_libs_6tslibs_12tzconversion_tz_localize_to_utc
Shadow bytes around the buggy address:
  0x0c047fffc330: fa fa fd fa fa fa fd fa fa fa 01 fa fa fa fd fa
  0x0c047fffc340: fa fa fd fa fa fa fd fa fa fa 01 fa fa fa fd fa
  0x0c047fffc350: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fffc360: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fffc370: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
=>0x0c047fffc380: fa fa fd fa fa fa[01]fa fa fa fd fa fa fa fd fa
  0x0c047fffc390: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fffc3a0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fffc3b0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa
  0x0c047fffc3c0: fa fa fd fa fa fa fd fa fa fa 02 fa fa fa 02 fa
  0x0c047fffc3d0: fa fa 02 fa fa fa 02 fa fa fa 02 fa fa fa 02 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==710467==ABORTING

Since we are only off by one byte it makes sense that this would only sporadically crash