incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radhika Puthiyetath <>
Subject RE: [DOCS][DISCUSS]Documentation for 4.1
Date Fri, 15 Feb 2013 03:43:16 GMT
Hello Doc contributors,

Thanks for the support. I would like to know other than Sebastian, Jessica, and I who are
willing to work on the 4.1 features.

I don't see anyone signed up for any features in the plan/ doc defect.

If you pick up, I would get a clear idea as to whether I need spend any long hours/ weekends:
I prefer not to slip the schedule ...


-----Original Message-----
From: Chip Childers [] 
Sent: Thursday, February 14, 2013 9:21 PM
Subject: Re: [DOCS][DISCUSS]Documentation for 4.1

On Wed, Feb 13, 2013 at 05:50:22PM +0100, Sebastien Goasguen wrote:
> On Feb 12, 2013, at 8:30 PM, Chip Childers <> 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
> >> 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.


View raw message