#234 Feature submission freeze needs to be before Feature Freeze
Closed None Opened 14 years ago by ausil.

Feature's need to be submitted and be accepted well before Feature Freeze. I would propose the cutoff be 1 day before the fesco meeting 4 weeks before Feature Freeze. that way FESCo can have them all approved 4 weeks before feature freeze. we then have 4 weeks to look at Features that need to most work to get completed and try make sure that all succeed. 2 weeks would probably work also but i think less than ideal.


I fail to see what "problem" this proposal is solving.

Can you explain why the significant changes you've proposed would benefit Fedora or fix something that is not currently working? Chopping a month off of the short development window we already have doesn't make sense to me.

Feature submission happening after Feature freeze doesn't work. developers have a false sense of when they need to land things. As came out in the special meeting we had to have to approve features, developers think they have until Alpha to land things Which is not and never has been true. Features have needed to be testable at Feature Freeze. With my proposal Feature list will be solidified earlier and we can spend more effort making sure that the proposed features will land and be complete. its not chopping a month off of development at all. development time wont change. all that changes is that the feature pages need to be there sooner.

IMHO, the primary reason for lateness in this F12 cycle is the Beta->Alpha rename. We're all used to the "Alpha" being a mostly unimportant milestone which is pretty far from the release. I think many of us are, conciously or subconciously, not realizing that the "Alpha" is now what used to be the "Beta", i.e. fairly close to the release, the (approximate (*)) date where most freezes happen. We are all humans, we take time to get used to changes.

(*) The extra time between feature freeze and alpha freeze is another issue, which is probably also a source of confusion as we didn't have that extra time in the past.

The problem to solve is the last minute scramble of feature submission and crash landing of content at or just after the feature freeze. This isn't about shortening development time at all, it's about putting a mark in the schedule when we'll last accept new feature submissions. I'd be a bit more aggressive and put the feature submission freeze only 2 weeks before feature freeze. The amount of development time remains the same, only the dates when new features can be proposed change.

Fair enough.

What about the inevitable 100% complete feature that someone wants to bring forward? FESCo has traditionally made exceptions for them and accepted them after Feature Freeze. I think they should continue to do so.

In the same way I would suggest that 100% complete features can be submitted up until feature freeze. I think FESCo should set a milestone when it will NOT accept ANY feature even if it is 120% complete and I will add it to the Feature policy.

Replying to [comment:5 poelstra]:

I think FESCo should set a milestone when it will NOT accept ANY feature even if it is 120%
complete and I will add it to the Feature policy.

IMHO, it's always good to have wiggle room. If you set a final date for features, someone will come looking for an exception the day after with a 100% feature, QA signed up to test it, release note added and marketing folks happy to include it.

Yes, add a feature submission date. The further it gets past that date, the harder it should be to get an exception. But exception requests should still be considered if they meet the QA/ release notes/marketing criteria. The process must be seen to be reasonable and not inflexible process-for-process-sake.

IMHO we should also have a process for features added by updates. It feels bizarre to see features advertised as "Fedora n features" when they have been available in Fedora n-1 (and in some cases even n-2) updates for months.

I still think a month before feature freeze is too early; maybe two weeks is better. In the same veins, some sort of sliding scale where as you approach freeze the percentage done needs to be higher might be useful.

Replying to [comment:8 notting]:

I still think a month before feature freeze is too early; maybe two weeks is better. In the same veins, some sort of sliding scale where as you approach freeze the percentage done needs to be higher might be useful.

I agree with Bill.

Replying to [comment:8 notting]:

I still think a month before feature freeze is too early; maybe two weeks is better. In the same veins, some sort of sliding scale where as you approach freeze the percentage done needs to be higher might be useful.

Except that I'm already a millionaire on paper from all the quarters I've collected from developers who say that "percentage completion is meaningless" :-)

The feature submission deadline will be moved to two weeks prior to feature freeze for Fedora 13. We'll revisit if needed.

Login to comment on this ticket.

Metadata