| spotz[m] | Spelling is hard yo! | 00:27 |
|---|---|---|
| fungi | especially the way we fund education in this country | 01:15 |
| *** elodilles is now known as elodilles_pto | 10:34 | |
| JayF | So far, only 4 (5 if I count for proposing it) tc-members have voted on https://review.opendev.org/c/openstack/governance/+/887083 -- it's important to land this ASAP so we can notify teams if we set a deadline | 10:38 |
| JayF | There is some disagreement there still, but I don't intend to change the resolution unless we have a consensus it's the wrong thing. | 10:39 |
| JayF | (this is re: SQLAlchemy 2.0 migration; an importnat item for us to track if we want OpenStack to be testing and requiring the same versinos of SQLA that distributions will be running) | 10:39 |
| dansmith | What is the actual deadline? The resolution says 2024.1 but doesn't say why. Is 1.3 being dropped from 24.04? | 13:29 |
| dansmith | because for projects (especially smaller less active ones) moving to 2.0 by early next year could be a pretty big hurdle, having to move off migrate and correct all the other little things that comes with it | 13:30 |
| dansmith | and given how setting a hard deadline has *never* worked for us, that's the crux of my concern about doing so | 13:30 |
| dansmith | if we remove the "we'll nuke your project if you don't make it" language, we can still set the deadline, get the communication out, and look at who is not able to meet it and decide what to do | 13:31 |
| dansmith | actually 2024.04 won't even be possible as a runtime for 2024.1, so even if that's the impetus I don't see that being a reason for such a short deadline on the projects. | 13:34 |
| dansmith | er, s/2024.04/24.04/ | 13:34 |
| dansmith | I think it's also relevant that as of 2023.1 you can't even install python packages into the system python environment so you need a venv anyway | 13:41 |
| fungi | yes, ubuntu 24.04 may not even be a viable runtime for our 2024.2 cycle, since there's a very good chance it won't even be available by the time we release 2024.1 | 13:42 |
| fungi | odds are we'll have ubuntu 24.04 in the pti starting for the openstack 2025.1 release, and then drop ubuntu 22.04 testing in 2025.2 | 13:44 |
| dansmith | yeah, so I'm not sure what the sudden rush on this is | 13:44 |
| fungi | likely the bigger concern is that other python dependencies are migrating to sqla 2.x and dropping support for 1.x at the same time, so we may end up with a large swath of upper-constraints held back | 13:46 |
| fungi | but i don't know what the transitive dependency set looks like wrt which of our other dependencies also depend (directly or indirectly) on it | 13:47 |
| fungi | could be an interesting graphing project for someone who enjoys doing network analysis | 13:48 |
| dansmith | I'm not really sure what libraries we use that would depend on sqla.. if that's really a concern, it might be helpful to show some evidence there | 13:48 |
| fungi | agreed | 13:48 |
| fungi | without data it's hard to know what the impact could be | 13:48 |
| JayF | dansmith: I'm 100% onboard for changing the actual deadline as long as the evidence says we have the time; I took 2024.1 from the notes from the forum session | 13:52 |
| JayF | My main concern is that when our platforms start shipping sqla 2.0; we need to as well | 13:52 |
| JayF | In any event, we should get it documenteed ASAP. | 13:52 |
| dansmith | JayF: I think we should set the deadline, 2024.1 is fine. I think we don't need to get into threats that early, however, without some reason to do so | 13:54 |
| dansmith | I'm totally on board with setting the deadline at 2024.1 ASAP if we remove the threat | 13:54 |
| JayF | I am mostly under the impression I'm just laying out the actual process; not adding more punitive pieces... e.g. if you aren't in line with global reqs -> you can't release -> you are inactive | 13:55 |
| dansmith | right, but saying we' | 13:55 |
| dansmith | saying we're going to mark you inactive in 2024.1m2 if you haven't met it, when the actual requirement is further off is not cool IMHO | 13:55 |
| JayF | Yeah, I mean to reflect the actual technical deadline | 13:56 |
| JayF | not to artificially pull it in | 13:56 |
| dansmith | personally I think this is a little more "there's a new version of this library that we as purists think we should be on already" -itus. | 13:56 |
| JayF | I'm going to put a comment on that resolution that I should include the distro information about why the deadline is what it is | 13:56 |
| JayF | and in the process move it if 2024.1 isn't the right place for it | 13:56 |
| dansmith | so keep the threats but move the deadline for punishment out further? | 13:57 |
| JayF | It's not threats; it's reflecting the reality that you can't release if you aren't coinstallable... not stating that up front and trusting a busy contributor to connect those dots themselves seems weird to me | 13:58 |
| JayF | I keep feeling like there's some moving part I'm missing here because I don't understand how it seems punitive to say "if you can't install using the versions in our testing platform, and pass tests with them, you are inactive" which AIUI is already the policy | 13:58 |
| fungi | fwiw, debian bookworm, which just released last month, ships a python3-sqlalchemy 1.4.46 package, debian testing and unstable still have 1.4.47, and only debian experimental contains a 2.0.18 package for evaluation | 13:59 |
| dansmith | fungi: yeah, hence my feeling there's a real mismatch here | 14:00 |
| JayF | https://review.opendev.org/c/openstack/governance/+/887083/3#message-5cbdfad48a1f5769d218bbdd402879e3eb7bd5f1 | 14:00 |
| JayF | I'll get more supporting evidence, and if the evidence says, change the proposed deadline | 14:00 |
| dansmith | JayF: in the past, demands and threats like this have led to pushback on things being forced. as ironic is one of those projects that usually has its own idea about things, especially releases and support intervals, I guess I would think you'd sympathize there | 14:00 |
| dansmith | JayF: I honestly think that a lot of the reason glance has nearly refused to support OSC in the past is because they were told they had to | 14:01 |
| JayF | Technical requirements do not get the luxury of taking feelings into account :(. If we didn't have the global requirement piece forcing a semi-atomic changeover, I would not be in favor of a hard deadline at all. | 14:02 |
| fungi | for that matter, where did someone say sqla v2 was coming in ubuntu 24.04? mantic (the 23.10 version under development) carries 1.4.47 still (presumably synced to debian/testing, so i would only expect 24.04 to have v2 if debian can manage a transition for it in testing before the ubuntu 24.04 freeze deadline) | 14:02 |
| dansmith | so, everyone knows the policy is that you can't not work with the global requirements, but telling people they have to move off of a tool (migrate) and library (sqla 1.x) or else there's going to get fired is just more combative than it needs to be at this phase, IMHO | 14:02 |
| dansmith | fungi: right, I have no idea, hence my asking | 14:02 |
| dansmith | fungi: and also hence my feeling that this is new-stuff-itus :) | 14:02 |
| JayF | I think we just disagree about how to send the message; I think it's friendlier to say "bad news first" rather than present a deadline and then have someone surprised when that leads to inactivity | 14:02 |
| fungi | i'm going to wager that sqla v1 will still be in ubuntu 24.04 | 14:03 |
| dansmith | fungi: agree | 14:03 |
| JayF | fungi: yep, my big takeaway from this conversation is that taking the timeline from the forum session was a mistake | 14:03 |
| JayF | one that I already committed to correcting in gerrit | 14:03 |
| fungi | sadly i had too many conflicts to make every forum session, so wasn't there to fact-check assertions | 14:04 |
| dansmith | yeah I wasn't there either so it's hard for me to speak to the content from just the notes | 14:04 |
| *** d34dh0r5- is now known as d34dh0r53 | 14:04 | |
| dansmith | JayF: I think the bad news being "everyone needs to work on SQLA 2.0 support because that's the rapidly-approaching future and we'll be changing the requirement soon" is more than enough for competent software engineers to handle | 14:05 |
| dansmith | since we have more time than was previously advertised to measure progress and handle the policy-driven consequences if we need, I think we should be able to make this a goal with an expected deadline and not a "we'll make you inactive on March 2 2024 if you don't meet it" | 14:06 |
| fungi | anyway, i think you're both right wrt to the "deadline" problem. we have an aspirational deadline of "soon" to try to encourage teams to get that work underway and not dally, but on the other hand the technical deadline of "the old version will exclude you from pti requirements" is farther off and that's where you get dropped from the release | 14:06 |
| dansmith | in the past we've had people get close and not make it, and since we have no very close pending deadline, we should be able to handle that situation at the time, if it arises with the details that can only be known then | 14:06 |
| JayF | Yeah; I'll try to make the language more friendly in the next resolution | 14:06 |
| JayF | it's clear I missed the mark of perception in that | 14:07 |
| JayF | but I do feel strongly if a project missing the deadline is putting it one foot into the inactive bucket; it's much nicer to say that up front | 14:07 |
| fungi | i do think it's fair to mention (if people find it necessary to include the reminder) that eventually depending on the old version will prevent a project from being able to still get included in the release | 14:08 |
| dansmith | or link to some policy | 14:08 |
| dansmith | but yeah, if they really need to be reminded, then sure | 14:08 |
| dansmith | but I think we're a long way off from needing to provide an execution date :) | 14:09 |
| fungi | missing goal deadlines hasn't ever (to my knowledge) meant exclusion from the release, but it is certainly a data point to indicate that a project might be trending toward inactivity | 14:10 |
| dansmith | yeah | 14:10 |
| dansmith | glance is a few years past the OSC one ;P | 14:10 |
| JayF | fungi: My perspective was more; being incompatible with requirements /can/ exclude you from a release, yeah? | 14:10 |
| dansmith | let's take the obvious example: | 14:11 |
| fungi | yes, but being incompatible with requirements (in the sense of what ubuntu version will have sqla v2) is at least two years out for our pti, maybe 4 years out | 14:11 |
| dansmith | if keystone doesn't make the deadline (especially if there is no burning reason we have to have that deadline), we're not going to not release keystone. we're going to not merge the requirement, | 14:11 |
| dansmith | or make it all-hands-on-deck to help get them fixed | 14:11 |
| JayF | My hope, in general, is that all-hands-on-deck to fix projects will happen for those that have interested contributors running it | 14:12 |
| JayF | that goes for integrators that ship those projects, too | 14:12 |
| dansmith | we'll see | 14:13 |
| dansmith | I think forcing a non-voting unit job into everyone's queue that runs on sqla 2.0 might be reasonable so that it's flagged.. its a use of resources, but only on less-active projects so not a huge deal | 14:13 |
| JayF | At least in experimental queue | 14:14 |
| JayF | so it can be kicked to check status | 14:14 |
| dansmith | well, that won't have the same effect of being a constantly-failing job that people can see, which was my point | 14:14 |
| dansmith | it's easy to ignore non-voting failing jobs of course, but.. it's something | 14:15 |
| JayF | My hunch is that for the projects that might actually be in peril; we might have very few people, if any, to see them failing :( | 14:15 |
| fungi | it would probably be more for purposes of easily surveying projects to see which ones have successfully transitioned | 14:15 |
| fungi | so that the goal champions can measure progress across services | 14:16 |
| JayF | yeah | 14:16 |
| dansmith | yep | 14:16 |
| JayF | thanks for the chat; I understand where you're coming from a lot more now | 14:16 |
| JayF | it was never my intention for that deadline to be artificial and if it is, I'll fix it up (and if it isn't, I'll have evidence ... but I think we're at the point of '2024.1 is likely too soon') | 14:17 |
| fungi | and for that, you don't necessarily even need to put it in the experimental pipeline. the goal champion can just push a dnm change to each project which adds the sqla v2 eval job (ideally also clearing out other jobs so that they don't waste resources on those changes and possibly speed up the reporting as well) | 14:18 |
| JayF | stevenfin did that for Ironic when we were doing some of the transition | 14:18 |
| fungi | abandon the change when done checking. restore it later and rebase if needed to recheck progress | 14:18 |
| JayF | and I'll say, I think we'll be willing to help any projects struggling | 14:18 |
| JayF | that's at least how it should work, but I can only speak for me | 14:18 |
| gmann | agree with the deadline with some reason and early deadline is good. | 15:00 |
| gmann | for threat I have also given a few example of past exp one is swift not ready for py3 and dropping-py2 in aligned with OpenStack prjects, OSC, uWSGI etc | 15:01 |
| gmann | I am strongly against of project inactive as outcome of anyone not doing any work | 15:01 |
| dansmith | yeah, glance and wsgi is another good example | 15:02 |
| dansmith | I feel that one very specifically since I got pushback trying to do it for them | 15:02 |
| gmann | deadline + early non voting job reflecting the future failure for that project is good direction | 15:02 |
| gmann | I am 200% sure, if we go with the project inactive way then we might end up making 50% of the OpenStack projects inactive including major one like keystone etc where things are merging very very very slow | 15:05 |
| gmann | Right direction will be: 1. set deadline 2. create clear migration plan 3. add testing to show failure/work needed 4. help projects with less contributors/have-less-idea about work is right direction. last one stephenfin is already doing since long | 15:21 |
| dansmith | ...especially since we have a pretty long runway, as it turns out | 15:42 |
| gmann | I am thinking if we have time for hard stop on old sqla then why not we drive this work as community-wide goal. resolution is ok but community-wide goal is better way to plan and finish the work. that is more clear communication to community than resolution. | 16:35 |
| gmann | or both maybe. commented in review | 16:35 |
| gmann | ah just read the log where dansmith mentioning it doing as a goal . ++ on that | 16:40 |
| gmann | and testing, non voting or DNM testing patches (we do when we migrate distro version) has been a key driver for such migration | 16:41 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!