<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 8:17 AM, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">----- Original Message -----<br>
> From: "Anne Gentle" <<a href="mailto:annegentle@justwriteclick.com">annegentle@justwriteclick.com</a>><br>
<br>
</div>>8-------->8-------->8-------->8-------->8-------->8<br>
<div class="im">> On Jul 11, 2013, at 9:16 AM, Shaun McCance <<a href="mailto:shaunm@gnome.org">shaunm@gnome.org</a>> wrote:<br>
><br>
> > On Wed, 2013-07-10 at 15:46 +1000, Tom Fifield wrote:<br>
> >> On 10/07/13 15:40, Andreas Jaeger wrote:<br>
> >>> On 07/10/2013 02:34 AM, Tom Fifield wrote:<br>
> >>>> I'll take a bullish line, which may not necessarily be achievable:<br>
> >>>><br>
> >>>> """<br>
> >>>> On the day that the press release for Havana is sent out, we need -by<br>
> >>>> hook or by crook!- to have installation instructions for RHEL and<br>
> >>>> Ubuntu, and ideally SUSE and Debian too.<br>
> >>>> """<br>
> >>><br>
><br>
> I'd like as many helpers on this as possible and focus on this effort.<br>
> Andreas it sounds like you want to make this happen for SUSE.<br>
><br>
> Do we stop single sourcing with conditions for each op sys?<br>
<br>
</div>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?<br>


<div class="im"><br>
> >>> What kind of instructions are you looking at? The "Basic installation"<br>
> >>> ones, the current "installation guides" - or both?<br>
> >>><br>
><br>
> I think we want one guide that starts simple and goes to complex with<br>
> multiple example architectures. Note this is the opposite of what we have<br>
> been doing so far.<br>
<br>
</div>+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.<br>
<div class="im"><br>
> >>> Andreas<br>
> >><br>
> >> Thanks for the reply!!<br>
> >><br>
> >> I think the answer is: "something" ;)<br>
> >><br>
> >> My personal impression is:<br>
> >> * the basic install guide is too basic right now<br>
> >> * the install guides are too heavy<br>
> >><br>
><br>
> Heh. I think the basic is too complex because of the networking. But your<br>
> eyes are fresh.<br>
<br>
</div>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.<br>


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


<br></blockquote><div><br></div><div style>In past releases we released all books from the repo. I think this is going to change and only a selected set will release on release date. </div><div style><br></div><div style>

The criteria for release was the number of bugs in the backlog, a judgement call I made with the backing of the docs list. </div><div style><br></div><div style>I'd like to release on release date the selected documents we choose and dig into the Design Summit for once rather than continuing to have stress about the high number of bugs in the backlog and the as-yet-unreleased doc site. This means we need:</div>

<div style>- to choose which docs are released</div><div style>-to redesign a docs landing page for a release site</div><div style>-to redesign a "library" landing page for a set of docs that are useful but not tied directly to a release. The OpenStack Security Guide is written in this way.</div>

<div style>-to continue to track bugs and have a good judgement call for whether the selected docs are ready for release</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Thanks,<br>
<br>
Steve<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Anne Gentle<br><a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>
</div></div>