> I agree with Matt. Kickstart is not only a lowest common denominator > it is > a critical functionality for tons of our testing and deployment > tools. We > don't want revolutionary change in kickstart and we definitely cannot > have > it be broken. Slow, gradual change properly documented is critical > for > kickstart. > > I'm less concerned about changes in anaconda's UI if I know kickstart > will > continue functioning. OTOH the GUI is much more used than kickstart is. Shouldn't we aim for the same goal (100% functionality) in GUI as well? I'm trying to illustrate the point that "everything has to work" sounds great but can't be achieved. And particularly anaconda is far from it - afaik they don't have much unit tests, any CI, etc. If we don't define a critical subset of core commands, then everything will have to be questioned all the time. Release criteria are a way to define a set which doesn't have to be questioned (much). Surely you don't want to block F18 release just because autostep [1] might be broken? 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 and we didn't block the release on it. Other features are commands like multipath, driverdisk or zfcp (whatever on earth that is). Do you suppose we should block release on all these features, while we don't block on them using Anaconda GUI? We could word the criterion in such a way, that we require all kickstart commands to work except for those features we don't block even the GUI on. We could, but I'm afraid it's still a bit broad. My current pain point with release criteria is that we consider it all-or-nothing game - if it's in criteria it's a blocker, if it's not it's not. There a few exceptions, and a lot fudging when we need to cheat our own game (Adam is the guru here). I'd rather see criteria as recommendations - if it's not in the criteria, _you_ have to be very persuasive to illustrate why it should block the release; if it is in the criteria, _we_ have to be very persuasive to illustrate why it shouldn't block the release. If we understand the criteria this way, then I think these core kickstart commands are even more helpful. It your broken command is not among them, you might explain why this bug badly hurts a lot of people and it can be accepted, per-case. Or if you can promise you'll fix that bug within a few days, we can also block the release based on that fact. Currently our criteria interpretation doesn't allow for this flexible behavior. It's 1 or 0, blocker or non-blocker. (Hmm, this last paragraph might even deserve to be split into a separate thread.) [1] http://fedoraproject.org/wiki/Anaconda/Kickstart#autostep -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
