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 <[email protected]> wrote: > Master is for the next release anyway! > > - chip > > Sent from my iPhone. > > On Nov 16, 2012, at 7:41 AM, Joe Brockmeier <[email protected]> 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 >> [email protected] >> Twitter: @jzb >> http://www.dissociatedpress.net/ >>
