Closed ericholscher closed 1 year ago
Confirmed that urllib3 will not add a deprecation exception like urllib3 2.0 did. Because of this we will not have to worry about builds failing due to outdated libssl come Sept 11.
So, we can now set a date later in Sept (or even call it the first week of Oct) to give a bit more room for this migration timeframe.
We also don't need to be strict about the deprecation date now either. If projects aren't migrating over, we had talked about allowing some projects to continue building after the cutoff (big or long standing projects having trouble with the migration).
@agjohnson I'd like to move forward here, so just want to get some dates announced. I guess I don't understand the reasoning for changing the dates we agreed to on the call? Is there a specific worry you're trying to address?
Just gaining 3 weeks on our timeframe. We described the timeframe as fairly tight. We could rather quickly decide on Monday Sept 25 and keep everything else the same.
I'm fine with that date, and gives us room for a 3rd brownout if we need it.
That's a great idea. We could add another 24h or even 48h brownout on Sept 4 in place of the cutover.
Looks like everyone is planning on being around Mon Sept 25 too, just in case. We will have been through this 3 times at that point though, so I doubt there will be many fires then.
Note, before merging this, urllib3 might not be planning to add a deprecation exception like we saw in urllib3 2.0. This would allow us to relax the timeframe a little bit, and maybe aim for end of Sept instead. Still waiting on confirmation here, in #222