| opendevreview | Merged openstack/taskflow master: Remove Python 3.10 support https://review.opendev.org/c/openstack/taskflow/+/992698 | 00:48 |
|---|---|---|
| opendevreview | Merged openstack/oslo.config master: typing: Accept tuples to exception https://review.opendev.org/c/openstack/oslo.config/+/992761 | 00:54 |
| opendevreview | Merged openstack/oslo.config master: typing: Accept Sequence to ConfigOpts.__call__ https://review.opendev.org/c/openstack/oslo.config/+/992762 | 01:17 |
| gmaan | stephenfin: my only objection is to declare the support without testing it which is misleading. I replied on ML and gerrit, ++ on adding new template and make it voting but I am not sure it is needed to be done via testing runtime. I mean even testing runtime does not have it or TC reject the idea that does not mean oslo cannot test python 3.14 as voting and declare its support. | 01:35 |
| gmaan | and the new template can be adopted per library, if oslo team ok (which seems yes) then we can add here and if cinder team is not ok they can keep os-bricks on existing template used by service projects | 01:37 |
| gmaan | overall, i like the idea but do not hold it for oslo to adopt it if it does not get general consensus/in testing runtime. | 01:38 |
| tkajinam | honestly speaking I'm kind of tired of making 20+ changes to just add python 3.14 support although we need no changes in the repository side. as long as we see py314 test is passing at the time of update I feel like that's enough | 03:38 |
| tkajinam | more precisely speaking "just declare python 3.14 support" | 03:38 |
| opendevreview | Takashi Kajinami proposed openstack/tooz master: Drop Python 3.10 https://review.opendev.org/c/openstack/tooz/+/992605 | 04:51 |
| opendevreview | Takashi Kajinami proposed openstack/tooz master: Drop Python 3.10 https://review.opendev.org/c/openstack/tooz/+/992605 | 07:22 |
| damani[m] | hi there | 12:34 |
| damani[m] | can i please get a code review on that patch https://review.opendev.org/c/openstack/oslo.service/+/980790 | 12:34 |
| stephenfin | tkajinam: Me too. and it's much more than 20. I cound 39 (!) code deliverables in oslo 🌱 | 13:07 |
| stephenfin | s/🌱/🙈/ | 13:08 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.cache master: Refactor opts module https://review.opendev.org/c/openstack/oslo.cache/+/992631 | 13:38 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix mypy errors caused by new openstacksdk release https://review.opendev.org/c/openstack/oslo.limit/+/992911 | 14:30 |
| gmaan | damani[m]: will check today | 15:13 |
| gmaan | on py3.14, for me non voting testing is not a testing and it is always ignored when it start failing. | 15:14 |
| gmaan | tkajinam: stephenfin: may be some gloabl releasenotes at oslo level (not every deliverables) can do such things "add/remove support of python versions" but not sure how to do that as we do not have oslo level release notes. | 18:07 |
| gmaan | maybe release highlights can be used? but again that is the release notes which user might be reading for consistency | 18:08 |
| opendevreview | Clif Houck proposed openstack/oslo.config master: Better support Sphinx doc generation with custom option types https://review.opendev.org/c/openstack/oslo.config/+/992997 | 18:10 |
| stephenfin | gmaan: a bot proposed change would be helpful, like the translation tooling or the old zuul job bumps | 20:45 |
| stephenfin | it should be much easier to do now that every project is configured basically identically | 20:46 |
| stephenfin | I'll chat with fungi and clarkb about it next week | 20:46 |
| fungi | what specifically would the bot propose? just classifiers in pyproject.toml? | 20:47 |
| gmaan | ++ on bot and project can reject/edit if extra version testing is done there | 20:47 |
| gmaan | yeah | 20:48 |
| fungi | i guess more generally we'd want a pyproject.toml normalization job, which could be used to add/remove classifiers and also perform other standardization there | 20:48 |
| fungi | would it be done at the start of the cycle then, like by the proposed change generated after we create stable branches? | 20:49 |
| fungi | in theory, pti support decisions are supposed to be decided before the start of the next cycle, so prior to rc1 week | 20:50 |
| gmaan | basically when the generic template add/remove any python version voting job | 20:50 |
| gmaan | mostly it is start of cycle when stable branches are cut and master is for the next devlopment cycle | 20:51 |
| fungi | yeah, basically by rc1 we know the pti expectations for the next cycle, then we cut stable branches and adjust master testing for the next cycle, at which point pyproject.toml (and maybe other similar files) get a sync change proposed in master | 20:54 |
| fungi | though... branching for clients/libraries happen earlier, i guess they'd just wait until cycle-with-rc projects also get branches | 20:55 |
| gmaan | yeah, it is good as soon as master is open for the next cycle and that cycle need modification on python version testing. | 20:57 |
| opendevreview | Adam Harwell proposed openstack/castellan master: Add Kubernetes auth method to VaultKeyManager https://review.opendev.org/c/openstack/castellan/+/993057 | 22:52 |
| opendevreview | Adam Harwell proposed openstack/castellan master: Add Kubernetes auth method to VaultKeyManager https://review.opendev.org/c/openstack/castellan/+/993057 | 23:00 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!