#467 Make Feature Freeze happen sooner.
Closed None Opened 13 years ago by mattdm.

= Proposal topic =

Make Feature Freeze happen sooner.

= Overview =

Currently, the Feature Freeze happens about two months after a Fedora release, only one week before the Alpha Release. This is too soon. No-Frozen-Rawhide should enable an earlier feature development process. My suggestion is to have the Feature Freeze one month before Alpha Release.

= Problem space =

There's not enough time to make a good decision on whether a feature should be enabled by default (or included at all), and not enough time to fall back reliably if the go-ahead decision is changed.

= Solution Overview =

Move Feature Freeze to one month after previous Fedora Release, and one month before Alpha Release.

At the Alpha Change Deadline, a go/no-go decision should be made for each feature. This should be the major decision point, and the presumption should be that reverting will be the default. Features should be 100% complete, but need not be completely bug-free. (The "burden of proof" need not be high, but it should be on the feature.)

For features which go ahead, a final go/no-go decision should be made just before the Beta Change Deadline. Features must have no significant known bugs.

= Active Ingredients =

Feature developers, feature wranglers, QA team, alpha and beta testers, documentation writers, end users, FESCO, journalists, everyone.

= Owners =

Me! But you can have it if you like it.


Sorry, I missed the "Feature Submission Deadline", which is currently 2 weeks before the Feature Freeze. That's really what I'm talking about.

We can discuss this at our 2010-09-21 meeting.

Technically, Feature Freeze is currently three weeks (not one) before the Alpha release.

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Schedule_Methodology
https://fedoraproject.org/wiki/Releases/14/Schedule

It is a bad idea to bind Feature Freeze to the previous release AND the alpha release date because the space between each release differs over the time.

It is more helpful to say how many Tuesdays before the Alpha RC is composed that you wish Feature Freeze to land on.

Replying to [comment:1 mattdm]:

Sorry, I missed the "Feature Submission Deadline", which is currently 2 weeks before the Feature Freeze. That's really what I'm talking about.

This doesn't make sense. The submission deadline is the deadline that features must be submitted by to FESCo for consideration. "Feature Freeze" is what matters for what is "done enough" for the Alpha Release.

mattdm: Might you be able to attend the fesco meeting tomorrow?
19:30-21:30UTC in #fedora-meeting on irc.

It would be good to have you there to clarify.

Also, if you could provide a version of say the f14 release schedule thats been changed in the way you would like for f15 to be changed that would help us see the dates and what you are proposing.

I'll try to be at the meeting. Thanks.

Replying to [comment:3 poelstra]:

It is a bad idea to bind Feature Freeze to the previous release AND the alpha release date because the space between each release differs over the time.

It is more helpful to say how many Tuesdays before the Alpha RC is composed that you wish Feature Freeze to land on.

I think a certain minimum space on each side is important.

How about:

Feature Acceptance Deadline: Tuesday approximately two weeks after GA of previous release, with a minimum of four weeks before Feature Freeze. If a feature doesn't make this cutoff, that's fine, but it's targeted towards the subsequent Fedora release.

Feature Freeze: Tuesday one week before Branch Freeze Event. (Instead of simultaneously.) If the feature is not "substantially complete and in a testable state" as specified by the existing policy, it will be backed out of the current release at the Branch Freeze Event (and continue in Rawhide).

Feature Complete: Tuesday one week before the Beta Change Deadline. (Instead of simultaneously.) If the feature isn't ready to go, it will be backed out before the Beta Change Deadline.

The intention isn't to make things harder for anyone, but rather to focus development on Rawhide.

With these dates we would have lost many great features in the past. Think of rakudo or rakudo*, their schedule was tight, but we made it. Not to name many GNOME releases.

I think this proposal is drifting away from solving the originally defined problem which was "There's not enough time to make a good decision on whether a feature should be enabled by default (or included at all), and not enough time to fall back reliably if the go-ahead decision is changed."

I don't see how the Future Submission Deadline relates to solving the specified problem.

Based on the way our schedule methodology is currently set and the number of releases I've been proposing our schedule, I still fail to see the need to anchor the Feature Submission Deadline for the current release to the previous release GA date. It really doesn't work since the release schedules are constructed by starting with the GA and working backwards.

A "Go/No-Go" decision for each feature a week before the change deadline makes sense. Before adopting such a requirement I'd be careful to consider who would bears the responsiblity for determining whether a feature was ready or not and how bugs would be tracked for each feature. We considered creating tracker bugs for each feature a few releases ago, but the administrative burden was high and the ROI appeared low.

I'm not going to be able to make the meeting. But, in short, my concerns are:

1) Encouraging early development of features in Rawhide (and discouraging "sprinting" to cram a feature into an upcoming Fedora release).
2) Making sure there's well-understood and early-enough go/no-go decision points.

Thanks for thinking about this.

We discussed this today, but it was unclear what the exact proposal was here.

Also, I was thinking it might be good to do this as part of a release retrospective so we have all the data from the release and can decide what we want to change for the next cycle.

See discussion at:
http://meetbot.fedoraproject.org/fedora-meeting/2010-09-28/fesco.2010-09-28-19.30.log.html#l-521

Leaving open for next week or concrete proposals.

Matt: Can you give us a concrete change you want here?
(Preferably with F14 schedule diff so we can see what you want)

Or can we visit this when we talk about the f15 schedule and look at the entire retrospective?

There's a proposed f15 schedule at:
https://fedorahosted.org/rel-eng/ticket/4233

Can you see how it meets your request?
What (if anything) should be adjusted on it?

I'm going to close this now.
Feel free to reopen or provide more suggestion for the f15 schedule...

Yeah. Sorry, I've been really busy and distracted. I'll revisit later with more specific / articulate points.

Login to comment on this ticket.

Metadata