incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DOCS][DISCUSS]Documentation for 4.1
Date Thu, 14 Feb 2013 15:50:34 GMT
On Wed, Feb 13, 2013 at 05:50:22PM +0100, Sebastien Goasguen wrote:
> 
> On Feb 12, 2013, at 8:30 PM, Chip Childers <chip.childers@sungard.com> wrote:
> 
> > 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?
> 
> I am fine with this, but I'd like to see the schedule updated (otherwise it becomes meaningless).
> It's not an issue of translations, it's really an issue of procedure and schedule.
> 
> On the docs release, I think we need to have yet another thread :(. Docs code is part
of a release, but we may get updates prior to a bug fix release. It would be good to be able
to release new docs continuously. ( Jessica had started a thread about this).
> 
> -sebastien

Joe mentioned trying to organize a docs sprint during the irc meeting.  
Ideally, we would avoid any schedule change, but I've updated the release 
plan to reflect the fact that docs are not a hard freeze.

-chip

Mime
View raw message