Open Stack

Thank you Lana. I saw the meeting logs. I appreciate you guys discussing this. I understand the reasons to not do ‘only’. It may be a hassle to split the instructions up by distro right now; but it will be easy to make edits as we go.
I’ll propose an update to 317152 soon. 

Sincerely, 
Goutham

On 7/5/16, 7:06 PM, "Lana Brindley" <openstack at lanabrindley.com> wrote:

Circling back around on this one, and top posting so hopefully people notice ;)

After discussion at the Install Guide team meeting yesterday, we have determined that, for now, we will recommend that people do *not* use the ``only`` directive in their Install Tutorials to create a conditionalised book, as we don't have the infrastructure to be able to handle both conditionalised and non-conditionalised books at this stage. We will review this decision in the next few months, once we have things up and running correctly.

Currently, this will only affect Goutham's inflight manila patch (317152), AFAICT. Goutham, I'll contact you directly to discuss that.

I will also endeavour to update our instructions in the Contributor Guide to reflect this decision today.

Thanks for all the robust discussion on the mailing list and in the meeting on this topic. It's great to hear all the voices and be able to come to a consensus.

Lana

Thanks for all the discussion and viewpopints on this topic as  

On 04/07/16 15:57, Andreas Jaeger wrote:
> On 07/04/2016 07:33 AM, Lana Brindley wrote:
>> On 04/07/16 15:23, Andreas Jaeger wrote:
>>> On 07/04/2016 03:44 AM, Lana Brindley wrote:
>>>> Sorry for being late to the party. Right now, I think I don't fully understand all the issues, which is why I've been holding off. However, I think rolling with option 3 (let projects choose for now and revisit) seems sensible for the moment. I don't think it's wise to mandate (or ban) use of only at this early stage until we have a clearer picture of how it's being used (or abused).
>>>
>>> It's not use or abuse - it's far more complicated to use (both on
>>> tooling and reviewing) as well more difficult to generate a proper index.
>>>
>>> We've had quite some fun getting only right in our guides and still
>>> every now and then a change comes in that is supposed for one distro but
>>> breaks others. We now have some reviewers that know what to look for and
>>> how to review this - but this is a complexity that needs teaching to
>>> core reviewers in those project teams.
>>>
>>> Also, building with only means you have to build for each distro -
>>> that's a more difficult way of setting it up (needs extra scripts) as
>>> well you need to be careful with publishing so that we can use the same
>>> jobs for all projects.
>>>
>>
>> Thanks for the explanation, that's making more sense now. I still think that letting projects do what they want for now and reviewing later seems sensible, I think we need to gauge what's more broadly useful. I can see how banning only can make things easier for us, but I also think there's projects that might need it.
> 
> They ask here for guideance as well and my strong recommendation is to
> not use only.
> 
> Note that we have a single cookiecutter that uses the non-only version
> currently. Also, our documentation currently does not speak about only.
> 
> Our draft index page is not ready and I'm curious how that will look
> like with both variants.
> 
> I don't have the bandwidth right now to help project teams with an only
> setup. Is anybody up to help the project teams in case of problems and
> questions?
> 
> Lana, yes, we need to bring the pieces together and refine how we go
> there. So, we might say in half a year: Everybody use only, or nobody
> should use it. Right now, after reviewing changes that were proposed and
> completely broken due to only usage, I have a strong recommendation.
> Lana, your call on which way to experiment and then help the teams move
> forward,
> 
> Andreas
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com