> I think it's definitely too late for F18, in a moving-goalposts kind
> of way.
> But, I still would rather the criteria for F19 to be "all
> kickstart commands work, unless they're documented as experimental or
> unstable", and for F20 to be a step more strict.
>
> I think Kamil's actually done
On Fri, Dec 07, 2012 at 11:08:27AM -0800, Adam Williamson wrote:
> > 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,
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
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
> 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 cri
On Thu, Dec 6, 2012 at 7:41 PM, Adam Williamson wrote:
> Do I see two volunteers to help fix kickstart bugs? :)
If it came down to crunch time, and a kickstart bug was keeping us
from being able to do a release, you bet I'd volunteer to help fix the
kickstart bug.
--
Jared Smith
--
test mailing
On Thu, 6 Dec 2012, Adam Williamson wrote:
I'm less concerned about changes in anaconda's UI if I know kickstart will
continue functioning.
Do I see two volunteers to help fix kickstart bugs? :)
You see two people who are representative of the majority of linux users
in the world - speci
On Thu, 2012-12-06 at 11:29 -0500, Seth Vidal wrote:
>
>
> On Thu, 6 Dec 2012, Matthew Miller wrote:
>
> > On Wed, Dec 05, 2012 at 09:39:41PM -0800, Adam Williamson wrote:
> >>> I think that may be the case _now_ with our current Anaconda situation,
> >>> but
> >>> the more I think about it, th
On Thu, 6 Dec 2012, Matthew Miller wrote:
On Wed, Dec 05, 2012 at 09:39:41PM -0800, Adam Williamson wrote:
I think that may be the case _now_ with our current Anaconda situation, but
the more I think about it, the more strongly I feel about making this the
approach for future releases. When
On Wed, Dec 05, 2012 at 09:39:41PM -0800, Adam Williamson wrote:
> > I think that may be the case _now_ with our current Anaconda situation, but
> > the more I think about it, the more strongly I feel about making this the
> > approach for future releases. When there's _not_ a big Anaconda rewrite,
On Wed, 2012-12-05 at 12:13 -0500, Matthew Miller wrote:
> On Wed, Dec 05, 2012 at 09:54:45AM -0500, Kamil Paral wrote:
> > > Having depended on kickstart for years, I'm of the very strong belief
> > > that while it's okay to have a subset for alpha and beta blockers,
> > > *all* documented command
On Wed, Dec 05, 2012 at 09:54:45AM -0500, Kamil Paral wrote:
> > Having depended on kickstart for years, I'm of the very strong belief
> > that while it's okay to have a subset for alpha and beta blockers,
> > *all* documented commands should work for final unless they were
> > marked as deprecated
On 12/05/2012 02:37 PM, Matthew Miller wrote:
while it's okay to have a subset for alpha and beta blockers,
*all*documented commands should work for final unless they were marked as
deprecated and gave warnings in a previous release. (Preferably two
releases, since jumping one release is expecte
On Wed, Dec 05, 2012 at 09:54:45AM -0500, Kamil Paral wrote:
> > *all* documented commands should work for final unless they were marked
> > as deprecated and gave warnings in a previous release. (Preferably two
> > releases, since jumping one release is expected with our lifecycle.)
> I would pref
> On Wed, Dec 05, 2012 at 08:22:52AM -0500, Kamil Paral wrote:
> > I tried to make a core selection. I had the following in mind:
> > 1. Kickstarts are used for automation, therefore the most important
> > commands related to automation must work (manual intervention is
> > not fine).
> > 2. Comman
On Wed, Dec 05, 2012 at 08:22:52AM -0500, Kamil Paral wrote:
> I tried to make a core selection. I had the following in mind:
> 1. Kickstarts are used for automation, therefore the most important commands
> related to automation must work (manual intervention is not fine).
> 2. Commands which are
On Wed, Dec 5, 2012 at 9:15 AM, Kamil Paral wrote:
> I'm not fully decided either way, maybe a bit in favor; I hope some people
> will comment here as well. Just keep in mind we want to keep the core command
> set small.
I agree -- %include and %ksappend should be part of the core command
set t
> I make heavy use of the %include directive which I don't see that
> you've mentioned anywhere. It's a rather fundamental feature for how
> I use kickstarts through livecd-tools to effect dynamic sections. I
> suppose I could revise my tools to create a dynamic, yet monolith
> kickstart script, bu
> From: Kamil Paral
>
> In the discussion about
https://bugzilla.redhat.com/show_bug.cgi?id=869978
> we agreed that we should have a list of core kickstart commands that
> should definitely work for a Final release.
>
> All the options are documented here:
> http://fedoraproject.org/wiki/Anacon
In the discussion about https://bugzilla.redhat.com/show_bug.cgi?id=869978 we
agreed that we should have a list of core kickstart commands that should
definitely work for a Final release.
All the options are documented here:
http://fedoraproject.org/wiki/Anaconda/Kickstart
I tried to make a cor
20 matches
Mail list logo
