As proposed on the last FESCo meeting, I have agreed with Jaroslav to help him with the schedule for Fedora 23. I prepared a draft of the Fedora 23 schedule with the goal to release in the second half of October.
The risk I see in the schedule is Alpha release just before Flock conference start. So, if Alpha release slips, we might collide with Flock conference. Another thing to consider in the schedule is mass rebuild. The proposed solution is to start mass rebuild, if needed, 3 weeks prior “Branch Fedora 23 from Rawhide” task.
Thanks for drafting this up.
I agree about the concern with Alpha and Flock, but I don't think there's much to be done about it. At least a significant number of people that work on the release would be in a single spot. Hackfest time might be spent getting the release out ;).
We're already doing a mass rebuild for F23 that should be happening "Any Day Now" for the gcc C++ changes. It's been discussed several times, and as soon as Jakub tells us gcc is ready the plan is to kick it off. I would hope it's already done by May. We should probably take that into account when reviewing things. I'd suggest sending an email NOW telling people we'd like to not do 2 mass rebuilds and that they should let us know if they believe their Change would require one.
I'm gonna add F22 release to the schedule, above, if you don't mind — it helps me wrap my head around how this all fits together.
Flock was the issue last time too, in the end we skipped in schedule it as Alpha was delayed. But we can do it again the same way - sort it out when it's real problem. We just wanted to be sure it's mentioned here and people expects possible collision. I agree to try to avoid two mass rebuilds. Once we have the ack for schedule, changes submission deadline will be announced and part of it could be the prioritization of mass rebuild changes proposals.
So, what are we doing differently this time around to help ensure that the Flock conflict won't be as dire? Or what could we do that we aren't?
On the first, I think the practice of building early TCs is helping.
Would it help to bring the Alpha Freeze and Alpha Release (and possibly the branch, too?) one week earlier, giving us the possibility of a one-week slip without hitting Flock?
Replying to [comment:4 mattdm]:
This was one option we were considering with Jaroslav as well. Finally, I believe that giving one more week to development prior the Alpha Freeze is more valuable than having a spare week just to mitigate the risk of collision of Alpha Release with Flock.
If the risk of the collision will be considered as high, shrink of the period prior the Alpha Release is IMO the best solution how to mitigate it.
Would there be time to get "End user Requests"? And if so, What is that process, and lead-time?
Replying to [comment:6 lsatenstein]:
Not fully sure what you mean there. You mean just general input from any interested folks? I'd say we could surely mention the proposed schedule on devel and gather any feedback.
I see we are also missing "Side Tag Builds Deadline" which should be before "Branch Fedora 23 from rawhide" milestone and also "Software Translation Deadline" milestone which should be one week before "Beta Freeze".
I won't be able to attend today's meeting.
The schedule looks reasonable. I'm +1 for the schedule on which jreznik, mattdm, rel-engs and majority of FESCo agrees.
Replying to [comment:9 thozza]:
I won't be able to attend today's meeting. The schedule looks reasonable. I'm +1 for the schedule on which jreznik, mattdm, rel-engs and majority of FESCo agrees.
Same from me.
For comparison, here's GNOME 3.18 schedule: https://wiki.gnome.org/ThreePointSeventeen
My concern is that it doesn't align very well with the proposed F23 schedule.
When comparing the two schedules, the F23 final freeze starts 9 days before the GNOME 3.18.1 release. I think it would be very important to include .1 in the F23 GA release, since it usually comes with a lot of important and high profile bug fixes.
Would it be possible to move the schedule two weeks for this?
When we were drafting this schedule, the GNOME 3.18 wasn't available but I'm afraid two weeks will lead to early November release and that's something we were trying to avoid (in F22 schedule). On the other hand it would not be that late in November.
Can you remind me why we were trying to avoid an early November release? Because of possible slips and holidays?
If we release in May and November, it leads to a 6/6mo split. May/Oct is 5/7, which throws off the timing with other projects that are on a 6mo cycle. I think that is the overall generic concern that Kalev is expressing with the Gnome example.
(I fully realize development time does not start at the Change proposal submission date, but in practice we don't have many people that can split their time equally between working on Branched and Rawhide at the same time.)
The rule says "as close as possible to October 31st and May 1st of each year" and it usually fits first half of May and second half of October but earlier gives us some buffer to react to slips.
Ah, right. I forgot it was supposed to be May 1 and Oct 31, which leads to a 6mo/6mo split. It would be less confusing if we said May 1 and Nov 1.
However, the specific schedule concerns for F22 and F23 still stand. The F23 schedule seems to have inadvertently chopped off almost 2 weeks from our "rule", and it is "starting" almost a month late given the F22 GA date.
Thinking about it more, I'm leaning more towards pushing the dates out to actually match our rule here which would give us the 2 weeks back. If we're going to keep up the trend of being time based then I don't see an advantage in shortening a schedule like that. It seems we penalize developers twice. Once when we reject features that don't match the schedule and then again in taking the extra two weeks off to account for possible slips (which in turn makes some Changes even less possible).
Replying to [comment:11 kalev]:
For comparison, here's GNOME 3.18 schedule: https://wiki.gnome.org/ThreePointSeventeen Wed, 23 September: 3.18.0 Wed, 14 October: 3.18.1 My concern is that it doesn't align very well with the proposed F23 schedule.
I am not too worried about that. We got used to seeing the stable .1/.2 releases in Beta/GA due to Fedora slipping, which meant that the stable GNOME .0 release didn't get much exposure and important bug-fixes only landed in GNOME .1/.2. Ideally the GNOME .91/.92 would be in the Beta, which is the case here, so that the GNOME .0 is of higher quality.
From today's FESCo:
The schedule has been modified as agreed on FESCo meeting. Please check the schedule on wiki: https://fedoraproject.org/wiki/Releases/23/Schedule
the wiki page is empty
I can see the schedule contents on https://fedoraproject.org/wiki/Releases/23/Schedule page
It does work now, it was a caching issue with the wiki.
I see gcc5 mass rebuild is going on. Should we need then to specify mass rebuild in F23 schedule? Even if some other change needs mass rebuild that can be done in side tag I guess.
Replying to [comment:23 pnemade]:
I see gcc5 mass rebuild is going on.
It is not. It's a rebuild of only c++ using packages to get them all on the same ABI. So, this is a subset, and done a different way than a normal mass rebuild.
Should we need then to specify mass rebuild in F23 schedule? Even if some other change needs mass rebuild that can be done in side tag I guess.
mass rebuilds are always done in a side tag. ;)
We still need one for the hardening changes as well as gcc for all the non c++ using packages as well as possibly other changes for f23 we don't know yet.
Thanks Kevin for above reply.
Mass rebuild coordination ticket is https://fedorahosted.org/rel-eng/ticket/6162
This just came up — is there a deadline for NON-system-wide changes? I've been assuming that as long as whatever packages can get in, there isn't really a deadline until the beta freeze (or so), but that pushing it that long risks missing the boat. And that more importantly, if it's submitted after the system-wide change deadline and FESCo feels like it should be escalated to system-wide, whoops.
Is that basically accurate?
My understanding is similar to yours: "as long as whatever packages can get in, there isn't really a deadline until the beta freeze".
Changes which appears as system-wide after the system-wide change deadline should wait for the next Fedora release. Of course, there might be exceptions :-)
Replying to [comment:27 mattdm]:
This just came up — is there a deadline for NON-system-wide changes? I've been assuming that as long as whatever packages can get in, there isn't really a deadline until the beta freeze (or so), but that pushing it that long risks missing the boat. And that more importantly, if it's submitted after the system-wide change deadline and FESCo feels like it should be escalated to system-wide, whoops. Is that basically accurate?
In ideal world, we should have all proposed changes submitted by the deadline. I usually try to write it in the announcements in the way, it's deadline for all changes BUT for system wide changes it's the must and strict deadline. I'd say it works, as we mostly get self contained changes on the deadline but it gives more flexibility to accept self contained changes that makes sense later. And if self contained change turns to be system wide too late, we have the right not to approve it (or make an exception if it makes sense). It's the risk of submitting change too late.
Login to comment on this ticket.