#966 Fedora 19 Schedule proposal (DRAFT!)
Closed None Opened 11 years ago by jreznik.

Schedule draft
As we already slipped for 5 weeks and for the final release there is still no hard date (even we solved the issue with one more Beta slip), I started working on F19 schedule to check what are our options.

The idea is to overlap F18/F19 development to allow us target May as a release month for odd releases and minimize the effect on development. Final Change Deadline seems like a good candidate where to start planning phase - most of the Fedora 18 development should be already done, only release blocking issues are fixed during the freeze. With the F18 Beta change we are still able to hit second half of the May. GNOME releases, we are trying to be in sync with are considered in schedule - 3.7.90 to Alpha and Final for Beta.

  • 2012-11-26 Fedora 18 Final Change Deadline
  • 2012-11-27 Fedora 19 Planning & Development Begins
  • 2012-11-28 Start Fedora 19 Features Submission
  • 2013-02-12 Feature Submission Deadline
  • 2013-02-20 GNOME 3.7.90 release
  • 2013-02-26 Branch Fedora 19 from Rawhide
  • 2013-03-05 Alpha Change Deadline/Software String Freeze
  • 2013-03-19 Alpha Public Availability
  • 2013-03-27 GNOME 3.8.0 release
  • 2013-04-09 Features 100% Complete Deadline / Beta Change Deadline
  • 2013-04-23 Beta Release Public Availability
  • 2013-05-06 Final Change Deadline (with same -1 week as for F-18 Beta, will see how this works)
  • 2013-05-21 Final (GA) release

Other options are - redefine scope of Fedora 19, have a smaller release, and be more aggressive on aiming the beginning of the May. We can avoid the overlap of F18/F19 this way and start later too.

Btw. I do not consider here the requests for 9 months release cycle etc. There are also requests to prolong the period between Feature Complete deadline and Alpha change deadline to give developers a time to integrate new stuff (see systemd, Anaconda examples).


Some general comments:

Well, while checking F17 to F18, even three weeks were overlapping and I did not remember any bigger problems. So this way we could got 2013-05-14, closer to May 01th ;-) The idea to stick it to Final Change deadline was more to assure people are free to work on a next release.

I agree re: feature submission deadline.

The key thing in this picture is to make it very clear that people can literally be working on new things right now - could we not start accepting features now, just to prevent hesitation from people who might otherwise be working on the Next Big Thing from actually starting work?

Replying to [comment:3 rbergero]:

I agree re: feature submission deadline.

The key thing in this picture is to make it very clear that people can literally be working on new things right now - could we not start accepting features now, just to prevent hesitation from people who might otherwise be working on the Next Big Thing from actually starting work?

Big +1 here.

It would definitely helped if features were proposed earlier. We would have more time to review them.

Well,
for feature proposals earlier - I'm ok with that and actually now as we think we would be able to release Beta next week, it would be possible to add even one week to the schedule (with 2013-05-14 as a release date). I talked to David, it's an issue for Anaconda - but they can start on F19 only once F18 is released... And it does not make sense to block other teams.

For Feature submission deadline - I don't like the idea of having it so early. Especially not for that "leaf/self-contained" features as discussed on devel (I'm going to comment it in Feature process ticket). From my experience - people are asking for exception all the time, mostly for features that does not affect the rest of the system, so I'm ok with delivery by Feature 100% complete deadline.

Please discuss the schedule on Wed 07 meeting.

discussion of this ticket is postponed until F18 beta is out

Replying to [comment:3 rbergero]:

I agree re: feature submission deadline.

The key thing in this picture is to make it very clear that people can literally be working on new
things right now - could we not start accepting features now, just to prevent hesitation from people who > might otherwise be working on the Next Big Thing from actually starting work?

Pardon me for chiming in here...

Looking at F18 vs F19 proposed schedule, there's almost four month gap between F18 branch and F19 feature submission start - what exactly are developers supposed to be doing during that period? Many will be polishing F18 features sure, or working upstream, but this is a huge amount of time just thrown away for the people who either dont have F18 features in the first place, or have already dealt with them long ago.

It really should be possible to start working on features of the next release as soon as the current one gets branched, meaning it should be possible to submit features for the next version even before the branch to be able to maximize the development window.

As it is, I'm either going to have to twiddle my thumbs on Fedora front for several weeks till F19 features start getting considered (already filed mine...), throwing away lots of valuable rawhide testing-time, or breach the process and just go ahead with it anyway. I dont like either of these options.

The biggest problem with opening the F19 features just now is that the Fedora feature process is seriously broken and should be reworked before start of F19 features submissions. If we push the feature process revamp again to F20 we can as well say that there will never be any revamp of the feature process at all.

Also I don't think that you can't work on the development of the F19 features in rawhide any time now. At worst the changes would be reverted if the the feature is postponed or rejected. I expect developers to have fairly good estimate whether their feature is controversial or not and thus whether rejection of it by FESCo is likely or not.

Replying to [comment:10 pmatilai]:

It really should be possible to start working on features of the next release as soon as the current one gets branched, meaning it should be possible to submit features for the next version even before the branch to be able to maximize the development window.

As it is, I'm either going to have to twiddle my thumbs on Fedora front for several weeks till F19 features start getting considered (already filed mine...), throwing away lots of valuable rawhide testing-time, or breach the process and just go ahead with it anyway. I dont like either of these options.

As far as I know, there's nothing preventing you from working on your Feature as soon as F18 was branched. You can do this in rawhide right now. There really isn't anything forcing you to sit around and do nothing. If there is, let us know!

If for some reason you think your Feature is going to be very invasive or involve a lot of extra effort across the distro, you can always open a ticket here even if the Feature process hasn't started.

Replying to [comment:12 jwboyer]:

As far as I know, there's nothing preventing you from working on your Feature as soon as F18 was branched. You can do this in rawhide right now. There really isn't anything forcing you to sit around and do nothing. If there is, let us know!

My "feature" is simply a new major rpm version, and it either is in rawhide getting tested or it's not, there's no other "working on it" involved at this point.

If for some reason you think your Feature is going to be very invasive or involve a lot of extra effort across the distro, you can always open a ticket here even if the Feature process hasn't started.

As rpm affects every single package in the distro, it's explicitly stated as being a feature always. The one single time I've tried to go ahead without having it an accepted feature (the whole feature process was so new I didn't neven know it existed) I got enough "you naughty naughty boy" messages on fedora-devel that I'd rather not see that again. But maybe by now enough people consider the feature process broken enough not to matter...

Anyway, my intention was just to +1 and underline the need to allow the feature submission + consequent processing MUCH earlier in the cycles than it is now (and in general, not just F19), using my "feature" as an example. Based on these responses it appears to have come out as whining about my personal pet peeve instead, apologies for that.

Replying to [comment:13 pmatilai]:

Replying to [comment:12 jwboyer]:

As far as I know, there's nothing preventing you from working on your Feature as soon as F18 was branched. You can do this in rawhide right now. There really isn't anything forcing you to sit around and do nothing. If there is, let us know!

My "feature" is simply a new major rpm version, and it either is in rawhide getting tested or it's not, there's no other "working on it" involved at this point.

I figured as much.

If for some reason you think your Feature is going to be very invasive or involve a lot of extra effort across the distro, you can always open a ticket here even if the Feature process hasn't started.

As rpm affects every single package in the distro, it's explicitly stated as being a feature always. The one single time I've tried to go ahead without having it an accepted feature (the whole feature process was so new I didn't neven know it existed) I got enough "you naughty naughty boy" messages on fedora-devel that I'd rather not see that again. But maybe by now enough people consider the feature process broken enough not to matter...

Please open a separate ticket and we'll review it out-of-band. Personally, I'd rather see this land now in rawhide (or even a while ago) and get any issues fixed and tested ASAP.

For everyone that's thinking "jwb... you just made up a process on the fly!", no I didn't. This isn't process. This is common sense.

Anyway, my intention was just to +1 and underline the need to allow the feature submission + consequent processing MUCH earlier in the cycles than it is now (and in general, not just F19), using my "feature" as an example. Based on these responses it appears to have come out as whining instead, apologies for that.

I didn't think you were whining. I was more concerned about your specific case and the overall message, however it came across.

Note: IMHO, The Features process should be open for all future versions of Fedora at all times.

ie, we should accept proposals for F19 features or F20 features or whatever anytime folks know a timeline and details enough to propose them. I know in the past we have discussed N+2 features at the same time as N+1 without any issues. We should make sure people aren't thinking there is some magical time until they can submit.

Please schedule this ticket to Wed 28 meeting as stated in the comment #9 (to add to agenda again after F18 Beta). To plan the F19 timeframe - if we still plan May release, the schedule changes to accommodate needs of different teams (time to integrate after branching and before alpha) etc.

As for accepting F19 feature proposals - refinement is still needed, see ticket #896. Scheduling Feature submission beginning is more reminder - I agree, as we already have a few proposed F19 features (postponed F18 etc.). So it's more - how to proceed in case Feature process is changed - request changes to currently proposed features (or proposed before the changes) and I think it's doable and I'm willing to help FESCo as Feature Wrangler to work with feature owners.

Agreed on FESCo's 2012-11-28 meeting:

  • Feature sumission deadline pushed back to 1/29, we'll figure out the rest of the schedule based on submitted features.
  • FESCo agrees to initially target a end-of-May release with an end-of-February branch date, but may adjust outwards depending on submitted features. Schedule will be made at or shortly after the feature submission deadline.
  • jreznik will announce F19 features and timing.

You guys really aren't considering after all we went through in F18 development branch shortening the release cycle instead of lengthen it based on F18 experience? At least we in QA welcome more time not less...

On the other hand some developers feel the time for development is short even now.

A new proposal based on Mass rebuild date set to 2013-02-08 (https://fedorahosted.org/fesco/ticket/1000#comment:3) on the latest FESCo meeting + considering the scope of F19 features:

  • 2013-03-12 Branch Fedora 19 from Rawhide

(one month after the mass rebuild, one week for the automated rebuild + 3 weeks to manual fixes, it's one week earlier than usually to give developers more time for integration after branching and before Alpha Change Deadline)

  • 2013-03-26 Alpha Change Deadline/Software? String Freeze
  • 2013-04-09 Alpha Public Availability
  • 2013-04-30 Features 100% Complete Deadline / Beta Change Deadline
  • 2013-05-14 Beta Release Public Availability
  • 2013-06-03 Final Change Deadline
  • 2013-06-18 Final (GA) release

Btw. it pushes pressure on F20 schedule but if we begin the F20 planning/feature submission deadline right after branching (as we talked at FUDCon) + development, we can shorten it a little bit to avoid vacations :(

PS: I've added the meeting keyword but I'll be travelling and I'm not 100% sure I'd be able to join the meeting - please comment it before meeting, so I can work in your suggestions/ideas, thanks.

FESCo would like to add a week before alpha, pushing everything out a week:

{{{
2013-04-02 Alpha Change Deadline/Software?? String Freeze
2013-04-16 Alpha Public Availability
2013-05-07 Features 100% Complete Deadline / Beta Change Deadline
2013-05-21 Beta Release Public Availability
2013-06-10 Final Change Deadline
2013-06-25 Final (GA) release
}}}

Login to comment on this ticket.

Metadata