On Thu, Nov 08, 2012 at 05:44:41AM -0500, Jaroslav Reznik wrote: > ----- Original Message ----- > > On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote: > > > Adam Williamson wrote: > > > > The new anaconda UI and related features are more or less > > > > entirely the > > > > cause of the slip. > > > > > > This shows that those changes should not have been done, or at > > > least not in > > > this way. > > > > I think it's widely agreed by now that they could have been done > > better, > > the question is now exactly how we can improve the process. > > We have bigger issue with features that are OUT OF the process, > not communicated at all. If you take a look on New Installer UI, > it fits current design, it was a late as the scope was bigger > than Anaconda team thought but it's there. The scope was not a surprise to us, we knew from the beginning when we started this that the delivery of all newui work would have to be staged across multiple Fedora releases. The key was getting groups like Fedora QA and FESCo involved early so that they understood and would help us agree on what list of items should be priority #1, followed by priority #2, and so on. I think we had a lot of people in on that, but we didn't really fully communicate it well enough to each other. That can be improved in the future. > 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. 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? 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? It's complicated, but not impossible. [Also, these questions are intended as an example for how I can see both sides of the arguments, *not* catalysts for actual new arguments.] -- David Cantrell <dcantrell@xxxxxxxxxx> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
