Open Stack

----- Original Message -----
> From: "Anne Gentle" <annegentle at justwriteclick.com>

>8-------->8-------->8-------->8-------->8-------->8
> On Jul 11, 2013, at 9:16 AM, Shaun McCance <shaunm at gnome.org> wrote:
> 
> > On Wed, 2013-07-10 at 15:46 +1000, Tom Fifield wrote:
> >> On 10/07/13 15:40, Andreas Jaeger wrote:
> >>> On 07/10/2013 02:34 AM, Tom Fifield wrote:
> >>>> I'll take a bullish line, which may not necessarily be achievable:
> >>>> 
> >>>> """
> >>>> On the day that the press release for Havana is sent out, we need -by
> >>>> hook or by crook!- to have installation instructions for RHEL and
> >>>> Ubuntu, and ideally SUSE and Debian too.
> >>>> """
> >>> 
> 
> I'd like as many helpers on this as possible and focus on this effort.
> Andreas it sounds like you want to make this happen for SUSE.
> 
> Do we stop single sourcing with conditions for each op sys?

I think that single sourcing using conditionals is working OK and I'd prefer to see it stay, albeit with the installation materials consolidated into one source guide instead of conditionalizing two source guides. That said what alternative would you propose?

> >>> What kind of instructions are you looking at? The "Basic installation"
> >>> ones, the current "installation guides" - or both?
> >>> 
> 
> I think we want one guide that starts simple and goes to complex with
> multiple example architectures. Note this is the opposite of what we have
> been doing so far.

+1, I think this approach makes a lot of sense even with the core projects where users may wish to pick and choose some of them let alone if it ever becomes possible/necessary to add the integrated projects.

> >>> Andreas
> >> 
> >> Thanks for the reply!!
> >> 
> >> I think the answer is: "something" ;)
> >> 
> >> My personal impression is:
> >> * the basic install guide is too basic right now
> >> * the install guides are too heavy
> >> 
> 
> Heh. I think the basic is too complex because of the networking. But your
> eyes are fresh.

Networking setup, while complicated, is also pretty core to user expectations of a working environment. I guess the network node could be collapsed onto the controller for a basic setup (I suspect that argument has probably been had before  :)) but I'm not sure that significantly simplifies things.

>8-------->8-------->8-------->8-------->8-------->8
> > And I believe very strongly that your docs should be ready on release
> > day. They're part of your fanfare, and should be linked to from your
> > marketing materials.
> > 
> 
> I'm scared of this but we have to scope it for install docs at least, the
> board, technical committee, and especially the users expect it.
> 
> I don't think all docs can be ready at release, the scope is too wide. There
> are 30+  docs on an Openstack.org domains. My current thinking is that we
> will have a set of release docs (install and config only) and a set of
> library books that are not manuals tied to a release but merely guides. We
> may need to publish elsewhere to make this line strongly drawn, but I'm not
> sure we are ready to do that type of curation.
> 
> This distinction is especially important as we must prove we can deliver docs
> at release time.

So here's a related question, what determines whether a given document is ready for the release? Both in terms of what has been done in the past and whether or not we need/want to define a criteria that we're aiming for?

Thanks,

Steve