Open Stack

Thanks Goutham. Looking forward to your update.

L

On 07/07/16 12:08, Ravi, Goutham wrote:
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20160707/30f3e026/attachment.pgp>