Right now, the features process chart http://fedoraproject.org/wiki/Features/Policy/Process does not have a clear point at which the contingency plan is activated. There ''are'' some defined checkpoints at http://fedoraproject.org/wiki/Features/Policy/Dropping, but they refer to older freeze processes. I think it would help to make this more clear.
Additionally, the process right now calls for 100% code completion, explicitly allowing the feature to be untested. I don't see a defined point in the process at which the feature is examined for stability and functionality. This is especially important for features which are major changes (rather than all-new packages), since we risk regressions which (I say in the least dramatic way it is possible to say this) really do hurt Fedora overall.
Right now, the assumption is basically that once a feature is code-complete, we're past the point of no return. I'd like to see the addition of a standard, non-contentious, not ''too late'' checkpoint.
If the feature isn't ready at that point, it should be ''automatically'' re-targeted towards the next release. The point isn't to kill the features, after all -- just make sure they're ready for our users.
Replying to [ticket:980 mattdm]:
Additionally, the process right now calls for 100% code completion, explicitly allowing the feature to be untested.
Well, it has to be "testable" already by feature freeze. Having it actually tested requires someone to test it. Presumably the author of the feature has tested it and is by default satisfied by the state of the feature, so I'm not sure whether we can ask for more.
(This is where the proposed FESCo "feature shepherd" would be beneficial.)
We did effectively have a "status check deadline" during the F18 release process one week before the beta code freeze. In retrospect, a trouble with this deadline is, that there was "enough time" to let unfinished things through... but there isn't "enough time" to to revert them now. Either the checkpoint is so early that it is frequently waived, or it is so late that it can't be implemented.
Would it be too heretical to suggest perhaps the "testable" requirement should be timed not for the feature freeze, but already for the feature '''submission'''? That is a possible way to avoid the above dilemma, OTOH it might significantly impact the "First" of Fedora.
Replying to [comment:1 mitr]:
For leaf features, the contingency plan is usually "well, those packages didn't go in", or "those packages went in, but it's not really at the point where we should advertise this as a feature". For these, I think it's probably okay for development to continue up until the beta freeze, with testing until the final freeze.
For critical path changes, the problem is that there needs to be a window in which the work is done. If it's something like (to make up a feature) "Re-write all core components in the Go language", it seems like requiring the feature to be ready for testing before submission would invite gigantic, unmanaged change in Rawhide before there's a plan.
What would happen if we, for critical path changes, were automatically more strict at the beta code freeze point?
I tend to agree with mattdm. The heresy seems to take a lot of time from development phase, which would be really short than.
Deferred until a broader discussion of the Feature process is held.
We have an "check for contingency" point now. 1) Document/emphasize that this is when FESCo will decide on activating the contingency. 2) We recognize that deviations from that point will happen, but we don't establish a detailed policy for them at this time. 3) Close ticket, unless there are other changes. (+5,-0,0)
For the record, 1) was inserted into https://fedoraproject.org/wiki/User:Mmaslano/Feature_process .
Login to comment on this ticket.