Sure, why not keep the same spacing and see what happens.

Okay. I'm going to send this on to FESCo first thing tomorrow 2010-05-18 unless I hear any objections here. Thank you.

Looks good to me. Avoids Ubuntu's release nicely. I would like to change the "Final Freeze" and "Compose Release Candidate" items into one "Release Candidate Window" item that spans the 3 days (Tuesday/Wed/Thursday). The Freeze doesn't really happen until we have a release candidate, and that's when we start pushing 0-day updates instead of things into the stable release tree.

We need a deadline for when the last changes have to be in. I think "Final Freeze" accomplishes that. What happens during the "Release Candidate Window?"

Release Candidate Window is the start of when we'd like to be able to make our release candidate. This is the deadline you're talking about. The window is open until we reach the point of no return, that is the point in which if we don't have a release candidate yet, we have to slip, for we will not have enough time to validate before the go / no go date.

I'd definitely prefer having delivery of a release candidate on a specific date (not a range).

Was the "freeze" date not effective during Fedora 13?

The start of the release candidate window is our target date to create an RC. However if we miss that day, we have a couple more days where we could deliver an RC without immediately slipping. That's the window. Inevitably somebody will be late with something and miss the first day, I'd rather not have that cause an immediate slip.

As far as the freeze for Fedora 13, it wasn't quite "effective" because we didn't freeze until we had an RC, which was late Thursday, 2 days after the window opened for RCs.

Replying to [comment:9 jkeating]:

The start of the release candidate window is our target date to create an RC. However if we miss that day, we have a couple more days where we could deliver an RC without immediately slipping. That's the window. Inevitably somebody will be late with something and miss the first day, I'd rather not have that cause an immediate slip.

As far as the freeze for Fedora 13, it wasn't quite "effective" because we didn't freeze until we had an RC, which was late Thursday, 2 days after the window opened for RCs.

Oh I see. From QA's perspective, it went okay. We were expecting an RC on Thursday, and it was 50% delivered (i386 but not x86_64).

I don't object to any changes in the rel-eng schedule, it's obviously there to meet rel-eng needs. However, in the QA schedule, I'd like to keep the RC 'hand-off' to a single day. If we hit that target early, awesome! We have ways to coordinate expectations around RC delivery (TRAC tickets).

The problem as I see it is that the "single day" needs to come earlier rather than later. It should not be the last possible moment, because we'll never hit it. It should be set with enough time so that if we don't hit it, all is not lost, we have some wiggle room.

So lets set the RC date for the Tuesday of the week, but have an understanding that the RC may come as late as Thursday. And if we don't hit Tuesday, there will be changes made to the tree up to Thursday.

Replying to [comment:11 jkeating]:

The problem as I see it is that the "single day" needs to come earlier rather than later. It should not be the last possible moment, because we'll never hit it. It should be set with enough time so that if we don't hit it, all is not lost, we have some wiggle room.

I agree that all the work to build an RC can't happen in a single day. But I'm not tracking multiple days for when an RC will be available for QA. We need a date, not a range of possible days it might happen.

If releng needs more days in the calendar to prepare for the RC, can that information live in the team-specific rel-eng calendar?

Replying to [comment:11 jkeating]:

The problem as I see it is that the "single day" needs to come earlier rather than later. It should not be the last possible moment, because we'll never hit it. It should be set with enough time so that if we don't hit it, all is not lost, we have some wiggle room.

So lets set the RC date for the Tuesday of the week, but have an understanding that the RC may come as late as Thursday. And if we don't hit Tuesday, there will be changes made to the tree up to Thursday.

That would be like the IRS saying your tax return is due on April 15, but you have until April 18 to file. This isn't how to build a schedule because then we have to create a wiki page explaining that the deadline isn't a deadline. There are better ways to do this.

Touching on the IRC conversation from today--the release being on time is not soley the responsibilty of Release Engineering nor is it Release Engineering's fault when the release is late because a package in the distribution is broken. Release Engineering is responsible for composing the distribution, NOT its quality. If Release Engineering feels responsible or ashamed when the distribution is broken or late, that is separate problem to be solved, but it shouldn't be solved through the schedule or going to heroic measures release after release so it doesn't happen.

We make this more complicated that it needs to be by trying to squeeze as much stuff in as possible up until the last minute. This is not how good time based releases work (which we claim to be). This is what NFR was supposed to solve. I've proposed a slightly earlier "Final Change" date and a few other dates to see if we can get to something we all agree on:

https://fedoraproject.org/wiki/User:Poelstra/f14draft

Feel free to change the wiki page we can always do a diff to see what each person is proposing.

I agree that Release Engineering should not be shouldering the burden of whether a release makes it out on time. I'm not going to claim that developers don't get fussy about deadlines. But I've seen on other teams that sticking to a schedule lets us get away from worrying about who's the bad guy. If a deadline for a task occurs on the schedule, and the schedule's been accepted by the team, it's equally easy for anyone to refer to the schedule as authoritative. When we make things squishy on purpose, we create more opportunities for uncertainty and unease.

Screw it. Just set the RC date for Tuesday, and if we don't hit it, we can deal with it then. I'm tired of fighting for this issue.

Setting this as resolved, as it went through FESCo.