On 08/25/2011 10:49 PM, Stephen John Smoogen wrote: > On Thu, Aug 25, 2011 at 16:20, Adam Williamson<awilliam@xxxxxxxxxx> wrote: >> On Thu, 2011-08-25 at 14:35 -0600, Stephen John Smoogen wrote: >>> On Thu, Aug 25, 2011 at 14:25, Chris Lumens<clumens@xxxxxxxxxx> wrote: >>>>> 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. >>> I would go for the classical kickstart test for Alpha: >>> >>> Does it take a minimal kickstart and build a default system. The >>> minimal being the exact stuff that would be created if a person just >>> clicked through a release. >> Oh, I like that. That's very good. >> >>> For Beta >>> >>> Take these X broken kickstarts, does it bail at the appropriate places. >>> Take these Y working kickstarts, does it work. >>> Where Y is a set of items that can be tested on say a KVM or a >>> "default" desktop defined somewhere. >> I'm not so keen on that; it's a bit specific. One of my fetishes with >> the criteria is to keep them generic so they don't have to keep being >> changed all the time; I wouldn't want a criterion to rely on some >> specific kickstart file we keep lying around somewhere. > Well I was trying to suggest something that wasn't handy-wavy. At some > point a set of criteria are going to be needed for what is expected > out anaconda at the minimum. From that criteria a set of test > kickstarts can be built. If they dont' work then you have a blocker. > Is that better? > I'm still on the opinion that we should not be adding an ks testing to the alpha criteria. Cant we just create a set of most commonly ks use cases in ks files for releng and they can use pungi to test it with and post the result somewhere online with pass/fail more of an autoqa task and say all those must pass before beta? Where does the need for those ks testing suddenly come from and why do we need to have those ks test involved in alpha? JBG -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
