refining the feature process
mattdm at mattdm.org
Wed Sep 15 18:47:56 UTC 2010
On Wed, Sep 15, 2010 at 11:28:46AM -0700, John Poelstra wrote:
> I don't recall any situation where someone submitted a feature at the
> deadline without having done anything and then scrambling for two weeks
> to finish by feature freeze.
I'm looking at the current situation. If we had hard, earlier deadlines,
there wouldn't be the situation of scrambling to revert at the last minute,
and Lennart wouldn't have felt led-on and could now be happily working on
> > by the description of the Feature Submission Deadline as not being
> > really a deadline at all: "FESCo will consider features proposed after
> > this deadline on an exception basis."
> Exceptions have been few and far between, and only granted, to my
> knowledge, for features that were 100% complete.
I'm not opposed to allowing exceptions per se, and I trust FESCO to make
reasonable decisions. But in the documentation, the deadline is basically
defined as "a thing to which exceptions are considered".
I'm suggesting moving the Feature Submission and Feature Freeze deadlines
forward, so that decisions can be made before the alpha release.
But another suggestion is simply to put in more "should" wording,
encouraging early developement of features in Rawhide targeting
$NEXTRELEASE, rather than aiming for $PENDINGRELEASE.
Features with minimal potential for disruption could still target
> Those deadlines are set in such a way as to put as much development time
> as possible into a release schedule. From a release engineering
> perspective (the team proposing the schedules for approval by FESCo) it
> was determined that this was the highest value.
But that was before No Frozen Rawhide, and the parameters have changed. I
think it's worth reexamining them, to make better use of the new process.
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
More information about the devel