Add explicit date

[ericholscher]

No description provided.

[benjaoming]

In order to have the date visible quickly, I'm fine about merging this and adding other dates in a second iteration.

But if someone adds the brownout dates (+ nice with a definition of what we mean by that) in this PR, that's great, too 👍

[agjohnson]

Brought up in comments here, but maybe lets make this even easier on us and replicate what GitHub did: 12h window first date, 24h window the second date. I'm guessing it might be hard to have folks around for all of these 2h windows, thinking about this a bit more. We'll definitely catch more projects this way too.

[agjohnson]

If we start a 12h window Mon July 24 @ 0:00 PT and go till 12:00 PT, this is what the overlap looks like:

(I used the wrong date for some reason, but timing stands)

Asia users will get errors starting at the end of their day and the errors will resolve overnight, so not great, but we have more users in EU/US anyways.

[ericholscher]

Sounds good to me 👍

[agjohnson]

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

[agjohnson]

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).

[ericholscher]

@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?

[agjohnson]

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.

[ericholscher]

I'm fine with that date, and gives us room for a 3rd brownout if we need it.

[agjohnson]

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.

[agjohnson]

Three changes:

• Bump brownout Aug 7 -> Aug 14 to evenly space
• Sep 4 brownout for 48h added. If 24h seems more right, lets go with that though.
• Bump out cutoff date

[humitos]

This looks good to me with Anthony's suggestions 👍