Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Tue, 12 Feb 2013 14:30:31 -0500
From: Chip Childers <chip.childers@sungard.com>
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
Message-ID: <20130212193031.GK72518@USLT-205755.sungardas.corp>
References: <73EB847A-A354-4145-BFEB-6FB21A8EE9BD@gmail.com>
 <20130212165442.GA12099@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130212165442.GA12099@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Tue, Feb 12, 2013 at 10:54:42AM -0600, Joe Brockmeier wrote:
> On Tue, Feb 12, 2013 at 05:25:11PM +0100, Sebastien Goasguen wrote:
> > After 2/28 we will just fix doc bugs, not add new docs, even if a feature
> > is included in 4.1 if its docs are not in by 2/28 then too bad.
> 
> -1 to this.
> 
> The reason for stopping feature development with a hard freeze is that
> new features have the potential to disrupt the codebase badly enough
> that it's a major issue.
> 
> Adding new docs makes it a problem for translators, but it doesn't carry
> the same level of disruption as new features. For example, think about
> the impact if Javelin landed a week later than it did into master vs.
> the impact of adding another section to the install or admin guide. It's
> not really comparable. 
> 
> Also - leaving a feature out of a release means it can be picked up in a
> later release. Failing to document features is, basically, a bug that
> should be fixed (if possible) before a release. 
> 

Unless that feature's lack of documentation effectively just means that
it's not used (but available).

> > That's a bit of tough love, but that's what will happen if we want to 
> > stick to the schedule.
> 
> I'd like to stick to the schedule, but we should have more flexibility
> here than with features. It's also worth noting this is the first
> time through with a hard feature release and we're still finding our way
> - and what we seem to be finding is that ~1 month for documentation is a
> bit tricky when a lot of features land (or don't) right on the feature
> deadline. 

I actually agree with Joe for 4.1.0.  Right up until 2013-03-22, but
only as a way to give our docs folks a bit more time to catch up.  The
more that's done earlier the better.  The implication of this is that
our translations will suffer (i.e., not be done).  

We could have a post-release translation update planned, since the 
published docs site doesn't have to be part of a release officially.
BTW, do we have anything beyond en-US published to the website anyway?
If not, we should!

All that being said, I think that we need to work out a better schedule / plan for the 
next feature release.  I think back to the discussions about the schedule, 
and a general desire to consider "done" for a feature as meaning "coded, 
tested, documented".  Perhaps that has to become the criteria for next time?

> 
> Best,
> 
> jzb
> --
> Joe Brockmeier
> http://dissociatedpress.net/
> Twitter: @jzb
>