Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Toshio Kuratomi]

On Thu, Nov 08, 2012 at 11:07:08AM -0500, David Cantrell wrote:
> On Thu, Nov 08, 2012 at 05:44:41AM -0500, Jaroslav Reznik wrote:
> 
> > But the new upgrade process - it should be standalone feature,
> > we missed dracut feature, same for LVM in Anaconda (again, not
> > UI), live medias etc. So most of the problems were caused not by 
> > proposed/accepted features but by real features we weren't aware of.
> 
> Perhaps.  I think there is also a problem with a lack of what a feature
> actually is in Fedora.
> 
https://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_a_Feature

> In both of these examples, we could argue either way that they are features
> or not.  It's a new upgrade tool, yes, but it's really just moving the
> responsibility of upgrades to somewhere else.  So what's the feature?  If
> upgrades are the feature, we're not really changing anything are we?  We're
> changing how they're done but you're still getting an upgrade in the end.
> Or is the feature the fact that new code is arriving and old code is
> leaving?
> 
Ignoring your entirely legitimate questions, but applying the existing
feature definition, the change to the way we upgrade is a Feature:

1) highly user visible changes (beyond artwork or theme changes)
   * User no longer performs an upgrade by downloading the DVD/netinstall
     and booting from that.  The user now runs a tool from the previous
     release.
2) improvements or changes that require non-trivial cross-package
   integration
   * A new package is needed to support upgrades.
   * This new package must be done in the same release cycle as the anaconda
     release that removes internal support for performing upgrades.
   * This test is poorly worded for this sub-reason but the improvement also
     requires non-trivial cross-team integration.  The QA team needs to be
     aware that anaconda no longer does upgrades, that preupgrade no longer
     works, and that fedup performs that role.  They need to have time to
     adjust their tests to account for the new tool and to figure out how
     all that fits together in their release testing.
3) exciting new capabilities we can trumpet fedora having[...]improvements
   that are Fedora specific
   * This is a partial answer to your question about new code arriving and
     old code leaving.  The answer is that yes, new code may be a feature if
     we (Fedora contributors) are doing the work.
4) significant enough that if not completed properly or without a proper
   backup plan could delay the release
   * As we're seeing now ;-)
5) noteworthy enough to call out in the release notes
   * Most of our features fit this even if they don't fit the other criteria
     above.  Only a relative few, like the libboost upgrades that change ABI
     don't fit this.  Anything that fits criteria 1) should also fit here.

> Likewise with the LVM concern.  I completely see the argument from the
> storage team's perspective.  The entirety of LVM is a feature.  But I also
> see it from my team's perspective...we're really just changing a default
> option in our code.  So what's the feature here?  Who should own defaults
> and policy decisions?
> 
1) highly user visible changes (beyond artwork or theme changes)
   * Possibly.  I'm unclear as to precisely what has changed here.  If it's
     just the default but the user can select custom partitioning and is
     able to use LVM there, then this is less valid.  If it is no longer
     possible to customize the install to use LVM then this is very valid.
2) improvements or changes that require non-trivial cross-package
   integration
   * This test is poorly worded for this case but it is where I'd want to
     include this sort of thing if our Feature process for F19 doesn't get
     a drastic overhaul.  The change implemented by anaconda has a major
     impact on how the work the storage team is doing is presented.  Thus it
     needs to be coordinated with them.
   * We have had many past features that were about changing defaults and
     many that were about changing defaults in the installer (for instance,
     btrfs by default).  These were required to be features and one of the
     reasons was that it required code in anaconda to be changed to enable
     them.  It could be a trivial code change within anaconda but the
     anaconda team would need to know about it so that they wouldn't be
     surprised that the default was changing or that the code would need to
     be changed at all to effect that.
4) significant enough that if not completed properly or without a proper
   backup plan could delay the release
   * This one is hard to apply here.  Due to the release criteria, any
     changes to anaconda fall under this.  So tis definitely applies to the
     code changes.  The question is whether it applies to the case for LVM
     as a separate Feature from anaconda NewUI.

As for the question: "Who should own defaults and policy decisions?" -- the
answer there is FESCo.  For many pieces of software, defaults can be changed
without going to FESCo.  Unfortunately, for anaconda (and to a lesser
extent, the kernel and other core pieces of the OS), many of the defaults
that it implements are essential pieces of implementation of other Features
by other teams which hits Feature criteria #2.  Since anaconda (and the
kernel and a few other core pieces of the OS) are something that all user's
of the OS have to interact with, changes to default can have an effect on
how the user perceives fedora as a whole which hits Feature criteria #1.

It's not fair that so many of the changes you'd want to do to your software
are going to need to be decided (or at least evaluated) by FESCo whereas
oter pieces of software never have to be reviewed but it seems to reflect
the reality of how central anaconda is to defining what the Fedora
Distribution is.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121108/682d38bf/attachment.sig>