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.
Marcela
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...
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
