#8712 Consider changing freeze time
Opened 3 months ago by kevin. Modified 3 months ago

Right now we do freeze actions at 00:00UTC of the day they are listed on the schedule.

There's a number of issues with this:

  • People expect when they see 'freeze is tuesday' that they will have at least part of tuesday to finish things, when in fact the freeze takes effect right at the very first seconds of 'tuesday' and they don't have the time they expect.

  • 00:00UTC is early evening for releng folks in the us and late at night for releng members elsewhere. Making changes then can leed to mistakes or less review because fewer people are around. Issues are often not seen until the next day.

  • Other milestones (like release itself or unfreeze dates) don't take place at 00:00UTC, so it's also odd from that perspective.

I'd like to propose we move this from 00:00UTC on the day of freeze to 18:00UTC on the day of freeze. That gives people a chunk of the day to finish things, releng can do changes 20 hours later so it doesn't have to be in the middle of the night and it's more in line when we do releases. Another alternative might be to do 15:00UTC so it's the same as release time.

Thoughts?

@mohanboddu @bcotton


I would say we would then end up with people who are expecting to be able to make it work on Tuesday by end of business east coast still upset (as I remember that was why it was moved to later at one point). I would say that we either move it to:

Monday/Tuesday 23:59:59 so people know they have just til that time.
Monday/Tuesday 22:00:00 so 5pm on Monday East Coast it is done

I'd prefer to go with 23:59:59 UTC for simplicity's sake. I agree that the current setup makes it more confusing for folks when they see the date. I have a weak preference for keeping things on Tuesdays, because that makes it easier for people to send one-day reminders during the work week.

But as Kevin noted, we don't release at 00:00, so there's precedent for having some deadlines not occur on day boundaries.

As a reference, Python uses Anywhere on Earth. It is IMHO the best way not to confuse anybody. When it comes to freezes, I'd say the freeze would start when the day is over Anywhere on Earth. That is 23:59:59 AoE -> 11:59:59 next day UTC.

I would prefer having the release time which is actually 14:00 UTC, but that is still early morning in EST, which will not give enough time for people in US. I like AoE time that @churchyard has mentioned, which gives enough time for everyone in the world but that means late in the night in US and middle of the morning in Europe where our engineers are mostly located.

I am not sure if there is a perfect time for this, probably 12:00 PST (converted to UTC +/- 1 hr, because day light savings in PST) which gives some time for developers anywhere in the world and 15:00 EST and 21:00 ish in Europe (depending on where you are in Europe) where our release engineers are located, wdyt?

On Fri, Aug 30, 2019 at 12:59 PM Mohan Boddu pagure@pagure.io wrote:

mohanboddu added a new comment to an issue you are following:
``
I would prefer having the release time which is actually 14:00 UTC, but=
that is still early morning in EST, which will not give enough time for pe=
ople in US. I like AoE time that @churchyard has mentioned, which gives eno=
ugh time for everyone in the world but that means late in the night in US a=
nd middle of the morning in Europe where our engineers are mostly located.

I am not sure if there is a perfect time for this, probably 12:00 PST (co=
nverted to UTC +/- 1 hr, because day light savings in PST) which gives some=
time for developers anywhere in the world and 15:00 EST and 21:00 ish in E=
urope (depending on where you are in Europe) where our release engineers ar=
e located, wdyt?

What about 22:00 UTC which is ~ 5pm EST which covers a lot of users?

22 would be fine with me too. I just want to avoid 00:00 and 24:00 because they are both confusing.

Login to comment on this ticket.

Metadata