Maybe highlight release-slipping features?

Marcela Mašláňová mmaslano at
Wed Oct 31 12:03:48 UTC 2012

On 10/31/2012 12:38 PM, Scott Schmit wrote:
> On Wed, Oct 31, 2012 at 09:59:55AM +0000, "Jóhann B. Guðmundsson" wrote:
>> Given the current state of F18 I agree let's lengthen this release
>> cycle up to 9 months and arguably we should lengthen the whole
>                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> development cycle to 9 months from now on.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I'm not sure that helps -- then people just get more ambitious with
> their features and then what? Slow the release cycle down more?
> Remember, the whole point of regular, strict-timed releases is to keep
> things moving.
> What it appears we have is a development process where all features are
> optional in a given release except for Anaconda and any other feature
> accepted with no executable contingency plan (and there's usually at
> least one each release).
> I'm not certain that that's an entirely *bad* thing.  Some Features are
> necessarily big & disruptive and that always brings with it a risk of
> unexpected problems--shying away from those changes means you never do
> anything significant.
> IIRC, a Feature being big and impossible to revert isn't typically a
> surprise to at least one person on FESCo--I think more than once I've
> heard someone say "well, we knew that wasn't a contingency plan we could
> actually execute, but we had to do this."  But they may be (and
> sometimes have been) a surprise to others.
> Maybe we need to highlight those features that don't have a realistic
> contingency plan (the work to revert and re-test is greater than the
> work to complete) and call them out as "Critical Features" that we are
> committing to slipping a release for if they don't work well, rather
> than to revert them.
> I'm not terribly familiar with the release criteria, so this is
> something of a stab, but I suspect these Features from recent versions
> would be considered critical:
> * F15: Gnome3
> * F15: GCC46
> * F15: systemd
> * F16: Gnome3.2
> * F16: grub2
> * F17: GCC47
> * F17: Gnome3.4
> * F17: UsrMove
> * F18: Gnome3.6
> * F18: New Installer UI
> Also, with an explicit recognition of a Feature being critical, the
> planning process would naturally involve discussions like:
> * Should this Feature block the release?
> * Are we biting off too much in this release?
> * Can these features be broken into smaller, less-disruptive pieces?
> * This feature is going to need targeted testing
> * Hey, wait a minute, that's no ordinary Feature!
> * Hey, wait a minute, if we revert that at the last second, it'll blow
>    the testing schedule!
Well, we (FESCo) usually talk more about disruptive changes. The problem 
is that our opinions on what is disruptive and what is not can differ. 
Also if we have for one meeting more than 10 features then is very hard 
to really review the whole feature with all possible dependencies.
I believe we need to act according that in next release.


> Plus, in the big swamp of features we've been getting, it's harder to
> lose track of a critical feature that doesn't pop out of the list.
> And I'm not saying we don't do this already--systemd is a perfect
> example.  Everybody knew that it would slip the release if it didn't
> work and everyone (systemd developers included) worked to ensure that
> the impact was no greater than it needed to be, and pushed it out a
> release when it was recognized that it would be too disruptive for F14.
> On the other hand, New Installer UI seems to have slipped through the
> cracks.
> Just an idea...

More information about the devel mailing list