Re: Release criteria: kickstart

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux