Re: new criterion proposal: core kickstart commands

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

 



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



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

  Powered by Linux