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
Attachment:
pgpSWr9kkdXVB.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
