cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: documentation of tech previews
Date Fri, 16 Nov 2012 22:28:56 GMT

On Nov 16, 2012, at 10:03 PM, Chiradeep Vittal <Chiradeep.Vittal@citrix.com> wrote:

> I'm sure you mean the Query API and not the REST API. In fact, there is no
> REST API for AWS.

Yes my mistake. I meant Query API.

Thought the S3 tech preview is REST, correct ?


> 
> On 11/16/12 6:50 AM, "Chip Childers" <chip.childers@sungard.com> wrote:
> 
>> Let me clarify what I was trying to say:
>> 
>> IMO, we should have documentation for features that live in the master
>> branch.  If they are broken, then we should document where and how
>> they are broken (or, more preferably, fix them).  But if the code is
>> in the branch, and can be accessed, there's no reason to avoid it
>> going into the docs.
>> 
>> Right now, master is tied to our next feature release.  So to me, I
>> wouldn't remove any docs that are there.  If we have a functional
>> issue (examples include Nexus1000v and OVM support), I'd rather
>> everyone focus on fixing those issues.
>> 
>> Anyway, just my 2 cents.
>> 
>> -chip
>> 
>> On Fri, Nov 16, 2012 at 8:12 AM, Chip Childers
>> <chip.childers@sungard.com> wrote:
>>> Master is for the next release anyway!
>>> 
>>> - chip
>>> 
>>> Sent from my iPhone.
>>> 
>>> On Nov 16, 2012, at 7:41 AM, Joe Brockmeier <jzb@zonker.net> wrote:
>>> 
>>>> On Fri, Nov 16, 2012, at 03:35 AM, Sebastien Goasguen wrote:
>>>>> Jessica and I are having a discussion on
>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-464 .
>>>>> 
>>>>> At the core of the discussion is a question regarding the
>>>>> documentation
>>>>> of features that are still in development.
>>>>> In that particular bug, the core issue is that I talked about the REST
>>>>> interface in the AWSAPI docs.
>>>>> 
>>>>> I would like to get feedback and advice from the community on whether
>>>>> we
>>>>> should document features / code / tools that may be viewed as work in
>>>>> progress or tech previews.
>>>> 
>>>> Yes.
>>>> 
>>>> If we're shipping it, in any form, it's appropriate to document it. If
>>>> we know it's a WIP or "tech preview" then it should be labeled as such
>>>> in the docs with the warning that it may change in later versions.
>>>> 
>>>>> For instance, in addition to the REST interface for ec2 and s3
>>>>> (totally
>>>>> undocumented in the docs), I was going to start working on some
>>>>> introductory documentation for devcloud, marvin and cloudmonkey.
>>>>> 
>>>>> The wiki is nice for these but I believe they should start being
>>>>> documented in the official docs. We can add proper warning to users,
>>>>> explaining that they are still under development but that they can
>>>>> expect
>>>>> to see more complete features in the future.
>>>> 
>>>> +1
>>>> 
>>>> --
>>>> Joe Brockmeier
>>>> jzb@zonker.net
>>>> Twitter: @jzb
>>>> http://www.dissociatedpress.net/
>>>> 
> 


Mime
View raw message