> kickstart is a very broad area; you can write extremely complex > kickstart files that do a lot of stuff. So broadly what we'd need to do > is define a subset of kickstart functionality that we expect to work, > and then possibly divide that up by release phase (so some stuff must > work by Beta, the rest by Final, for e.g.) > > anaconda devs following this list, do you have any existing expectations > as to what level of kickstart functionality ought to be in place for > releases, and when you think would be appropriate? > > So far it seems everyone more or less agrees that it should be possible > to do at least a basic unattended kickstart install by Beta. You're right, kickstart is incredibly broad. I don't think we could ever hope to come up with criteria to cover all of it. I guess the best we can do is define criteria in terms of something else we already have. So, how much of the test matrix right now is tested via kickstart files? What other tasks do we have right now that are kickstart-based? I know spin composition uses some pieces of kickstart, and I know the storage tests I wrote for autoqa use kickstart. So right there, we have a couple things we could base criteria on. I guess there's also two ways you can break down kickstart - there's syntax, and semantics. Syntactically, the criteria should be that we recognize all valid kickstart files. Good luck defining what's a valid kickstart file in terms besides "that which is accepted by pykickstart as valid", though. Semantics are the hard part and are what we're really talking about here, though. That's a lot of words to say, "I don't know". - Chris -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
