On Fri, 2012-12-07 at 13:11 -0500, Matthew Miller wrote: > On Fri, Dec 07, 2012 at 07:27:58AM -0500, Kamil Paral wrote: > > Which brings me to another point. In kickstart there are commands which > > use a functionality we don't block the GUI on. For example there is a > > btrfs command, but until recenly btrfs wasn't displayed in Anaconda GUI > > I've read but not memorized the criteria for the installer, but I think in > general it's the case that things which are visible in the normal path in > the installer must work. > > The current documentation for Kickstart effectively puts all commands into > that category. It might be nice if they were sorted into critical and > not-critical commands _and documented as such_, but I think that needs to > happen *first*. (And I think you're on a reasonable track, by the way, and > have obvious put some thought into it.) > > Initially I said that if commands need to change or go away, they should be > marked deprecated for a release or two. Similarly, certain commands could be > marked as Experimental (btrfs) or Unstable (autopart, say). > > Then, once that's done, the release criteria are easy. That would be nice, but the fact is that we have to get releases done every six months, including supposedly one within the next two weeks, but we don't have any convenient guns to hold to the heads of the anaconda team to make them re-do the documentation. If we put in a criterion which says 'all documented kickstart commands must work' now, then we are committing to supporting them all for F18, unless someone magically re-does the kickstart documentation in the next two weeks, which doesn't appear likely to happen. We can't write a release validation process which works brilliantly so long as everyone else does things perfectly if everyone else is in fact _not_ doing things perfectly, because then it would lead to absurd results and there would be no trust in the process, and we'd go back to blocker-by-fiat. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test