You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Sebastien Goasguen <ru...@gmail.com> on 2013/02/12 17:25:11 UTC
[DOCS][DISCUSS]Documentation for 4.1
Radhika, raise some questions about the documentation for 4.1, so I would like to move this discussion to a new thread.
The 4.1 plan is at:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.1+Release
The feature freeze was 1/31 and the docs freeze is set for 2/28
To stick to a time based release that means (IMHO) that any docs that will not hit the docs freeze of 2/28 will not be part of the 4.1 release.
The actual feature, if it met the 4.1 feature freeze will, but not the docs.
Radhika prepared a documentation plan:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudStack+v+4.1+Documentation+Plan
Feature owners need to double check this plan, make sure that it only lists 4.1 features and then work on their docs.
We have 16 days left for docs freeze.
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.
That's a bit of tough love, but that's what will happen if we want to stick to the schedule.
Thoughts, flames ?
-Sebastien
RE: [DOCS][DISCUSS]Documentation for 4.1
Posted by Radhika Puthiyetath <ra...@citrix.com>.
Thanks Sebastien.
Here is list of what is in shape so far:
Additional VMX Settings - impacts only dev guide/ RN
Persistent Networks without running a VM - Admin/Dev guide/RN
AutoScale - Admin/RN
Support SRX & F5 inline mode - Admin/RN
Egress firewall rules for guest network - My patch is on Review board, waiting long for a reviewer !
Reset SSH Key to access VM (similar to reset password)
Support for EC2 Query API (rest interface)
Events framework to publish/subscribe to CloudStack events - Will finish this week, mostly!
Jessica, please add if I have missed any of your features.
I have started AWS-Style Regions, but I hear that is not yet in. Correct me Kishan.
The case is still almost the same about VMware dvSwitch. Correct me Satish; I do not know yet the feature is merged, and ready to document.
Status of the following features is in progress/ Open:
health monitoring for load balanced instances
Enhanced baremetal servers support on Cisco UCS
Scaling up CPU and RAM for running VMs
If you think I can pick up any of these features, let me know. We will get in touch with you tomorrow itself.
Thanks
-Radhika
-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com]
Sent: Tuesday, February 12, 2013 9:55 PM
To: cloudstack-dev@incubator.apache.org Developers
Subject: [DOCS][DISCUSS]Documentation for 4.1
Radhika, raise some questions about the documentation for 4.1, so I would like to move this discussion to a new thread.
The 4.1 plan is at:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.1+Release
The feature freeze was 1/31 and the docs freeze is set for 2/28
To stick to a time based release that means (IMHO) that any docs that will not hit the docs freeze of 2/28 will not be part of the 4.1 release.
The actual feature, if it met the 4.1 feature freeze will, but not the docs.
Radhika prepared a documentation plan:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudStack+v+4.1+Documentation+Plan
Feature owners need to double check this plan, make sure that it only lists 4.1 features and then work on their docs.
We have 16 days left for docs freeze.
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.
That's a bit of tough love, but that's what will happen if we want to stick to the schedule.
Thoughts, flames ?
-Sebastien
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Feb 26, 2013, at 1:01 PM, Radhika Puthiyetath <ra...@citrix.com> wrote:
> Hi Sebastien,
>
> I meant first set of feature documentation ready by 2/28, then next set of feature documentation (late entries) delivery on another milestone.
>
> If we have more than one milestone, or translation delivery (to Transifex) dates we might be able to accommodate all the features.
>
> Because I don't think AWS Style Regions will be done by the 2/28 milestone.
>
> Do correct me.
>
> Thanks again.
>
We agreed that the 2/28 deadline for doc freeze will slip a bit, leaving a smaller time frame for translation of the 4.1 release documentation.
Realistically the translations will be incomplete (except some of the UI and the runbook), our first concern should be to get as much of the needed documentation in.
So don't worry about missing the 2/28 date.
-Sebastien
> -Radhika
>
> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com]
> Sent: Tuesday, February 26, 2013 7:17 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
>
>
> On Feb 26, 2013, at 5:25 AM, Radhika Puthiyetath <ra...@citrix.com> wrote:
>
>> Hello Documentation contributors/ Localization maintainers,
>>
>> Would it be possible for us to plan multiple localization drop for documentation ? In that way, we can accommodate most of the late additions, for example, UI changes for AWS-Style Regions or any defect fixes on features.
>
> Radhika, I don't understand what you mean by localization drop ? can you explain ?
>
>>
>> Sorry about my ignorance if that is the way localization is dealt with currently by the translation team.
>>
>> Please do educate me also on the process followed for localizing the UI strings.
>
> If by localization you mean translation, the UI strings are translated the same way than the rest of the documentation. The source file has been uploaded to transifex and people are translating there. We also received a patch for korean translation via review board.
>
>
>>
>> Thanks
>>
>> -Radhika
>>
>> -----Original Message-----
>> From: Sebastien Goasguen [mailto:runseb@gmail.com]
>> Sent: Tuesday, February 12, 2013 10:43 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
>>
>>
>> On Feb 12, 2013, at 5:54 PM, Joe Brockmeier <jz...@zonker.net> 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.
>>
>> But if it cannot be fixed on-time it should not be a release blocker or a reason to slip the release date.
>>
>>>
>>>> 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.
>>>
>>
>> That's fine with me, it just means that we need to update the schedule.
>> And we need to make sure that what's in the 4.1 documentation plan pointed out by Radhika actually only targets features that made the 4.1 cut.
>>
>> -sebastien
>>
>>
>>> Best,
>>>
>>> jzb
>>> --
>>> Joe Brockmeier
>>> http://dissociatedpress.net/
>>> Twitter: @jzb
>>
>
RE: [DOCS][DISCUSS]Documentation for 4.1
Posted by Radhika Puthiyetath <ra...@citrix.com>.
Hi Sebastien,
I meant first set of feature documentation ready by 2/28, then next set of feature documentation (late entries) delivery on another milestone.
If we have more than one milestone, or translation delivery (to Transifex) dates we might be able to accommodate all the features.
Because I don't think AWS Style Regions will be done by the 2/28 milestone.
Do correct me.
Thanks again.
-Radhika
-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com]
Sent: Tuesday, February 26, 2013 7:17 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
On Feb 26, 2013, at 5:25 AM, Radhika Puthiyetath <ra...@citrix.com> wrote:
> Hello Documentation contributors/ Localization maintainers,
>
> Would it be possible for us to plan multiple localization drop for documentation ? In that way, we can accommodate most of the late additions, for example, UI changes for AWS-Style Regions or any defect fixes on features.
Radhika, I don't understand what you mean by localization drop ? can you explain ?
>
> Sorry about my ignorance if that is the way localization is dealt with currently by the translation team.
>
> Please do educate me also on the process followed for localizing the UI strings.
If by localization you mean translation, the UI strings are translated the same way than the rest of the documentation. The source file has been uploaded to transifex and people are translating there. We also received a patch for korean translation via review board.
>
> Thanks
>
> -Radhika
>
> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com]
> Sent: Tuesday, February 12, 2013 10:43 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
>
>
> On Feb 12, 2013, at 5:54 PM, Joe Brockmeier <jz...@zonker.net> 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.
>
> But if it cannot be fixed on-time it should not be a release blocker or a reason to slip the release date.
>
>>
>>> 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.
>>
>
> That's fine with me, it just means that we need to update the schedule.
> And we need to make sure that what's in the 4.1 documentation plan pointed out by Radhika actually only targets features that made the 4.1 cut.
>
> -sebastien
>
>
>> Best,
>>
>> jzb
>> --
>> Joe Brockmeier
>> http://dissociatedpress.net/
>> Twitter: @jzb
>
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Feb 26, 2013, at 5:25 AM, Radhika Puthiyetath <ra...@citrix.com> wrote:
> Hello Documentation contributors/ Localization maintainers,
>
> Would it be possible for us to plan multiple localization drop for documentation ? In that way, we can accommodate most of the late additions, for example, UI changes for AWS-Style Regions or any defect fixes on features.
Radhika, I don't understand what you mean by localization drop ? can you explain ?
>
> Sorry about my ignorance if that is the way localization is dealt with currently by the translation team.
>
> Please do educate me also on the process followed for localizing the UI strings.
If by localization you mean translation, the UI strings are translated the same way than the rest of the documentation. The source file has been uploaded to transifex and people are translating there. We also received a patch for korean translation via review board.
>
> Thanks
>
> -Radhika
>
> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com]
> Sent: Tuesday, February 12, 2013 10:43 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
>
>
> On Feb 12, 2013, at 5:54 PM, Joe Brockmeier <jz...@zonker.net> 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.
>
> But if it cannot be fixed on-time it should not be a release blocker or a reason to slip the release date.
>
>>
>>> 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.
>>
>
> That's fine with me, it just means that we need to update the schedule.
> And we need to make sure that what's in the 4.1 documentation plan pointed out by Radhika actually only targets features that made the 4.1 cut.
>
> -sebastien
>
>
>> Best,
>>
>> jzb
>> --
>> Joe Brockmeier
>> http://dissociatedpress.net/
>> Twitter: @jzb
>
RE: [DOCS][DISCUSS]Documentation for 4.1
Posted by Radhika Puthiyetath <ra...@citrix.com>.
Hello Documentation contributors/ Localization maintainers,
Would it be possible for us to plan multiple localization drop for documentation ? In that way, we can accommodate most of the late additions, for example, UI changes for AWS-Style Regions or any defect fixes on features.
Sorry about my ignorance if that is the way localization is dealt with currently by the translation team.
Please do educate me also on the process followed for localizing the UI strings.
Thanks
-Radhika
-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com]
Sent: Tuesday, February 12, 2013 10:43 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
On Feb 12, 2013, at 5:54 PM, Joe Brockmeier <jz...@zonker.net> 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.
But if it cannot be fixed on-time it should not be a release blocker or a reason to slip the release date.
>
>> 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.
>
That's fine with me, it just means that we need to update the schedule.
And we need to make sure that what's in the 4.1 documentation plan pointed out by Radhika actually only targets features that made the 4.1 cut.
-sebastien
> Best,
>
> jzb
> --
> Joe Brockmeier
> http://dissociatedpress.net/
> Twitter: @jzb
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Feb 12, 2013, at 5:54 PM, Joe Brockmeier <jz...@zonker.net> 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.
But if it cannot be fixed on-time it should not be a release blocker or a reason to slip the release date.
>
>> 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.
>
That's fine with me, it just means that we need to update the schedule.
And we need to make sure that what's in the 4.1 documentation plan pointed out by Radhika actually only targets features that made the 4.1 cut.
-sebastien
> Best,
>
> jzb
> --
> Joe Brockmeier
> http://dissociatedpress.net/
> Twitter: @jzb
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Jessica Tomechak <je...@gmail.com>.
On Fri, Feb 15, 2013 at 8:01 AM, Joe Brockmeier <jz...@zonker.net> wrote:
> Howdy Radhika,
>
> On Thu, Feb 14, 2013, at 09:43 PM, Radhika Puthiyetath wrote:
> > 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.
>
> It's helpful if you would include the URLs for easy reference so folks
> can quickly peek at what you're talking about.
>
> I believe you mean this page?
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudStack+v+4.1+Documentation+Plan#ApacheCloudStackv4.1DocumentationPlan-InstallationGuides%3AUpdate
>
> > 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 ...
>
> I've picked up the release notes and install from source. I may be able
> to pick up some others, depending on how those two go...
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
Joe,
Thanks for picking up doc tasks. The ones you picked are exactly the ones
that are further from Radhika's and my usual daily tasks, so they are
particularly helpful for you to attend to. Thanks again.
Jessica T.
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Joe Brockmeier <jz...@zonker.net>.
Howdy Radhika,
On Thu, Feb 14, 2013, at 09:43 PM, Radhika Puthiyetath wrote:
> 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.
It's helpful if you would include the URLs for easy reference so folks
can quickly peek at what you're talking about.
I believe you mean this page?
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudStack+v+4.1+Documentation+Plan#ApacheCloudStackv4.1DocumentationPlan-InstallationGuides%3AUpdate
> 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 ...
I've picked up the release notes and install from source. I may be able
to pick up some others, depending on how those two go...
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
RE: [DOCS][DISCUSS]Documentation for 4.1
Posted by Radhika Puthiyetath <ra...@citrix.com>.
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 ...
Thanks
-Radhika
-----Original Message-----
From: Chip Childers [mailto:chip.childers@sungard.com]
Sent: Thursday, February 14, 2013 9:21 PM
To: cloudstack-dev@incubator.apache.org
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 <ch...@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
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Feb 13, 2013 at 05:50:22PM +0100, Sebastien Goasguen wrote:
>
> On Feb 12, 2013, at 8:30 PM, Chip Childers <ch...@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
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Feb 12, 2013, at 8:30 PM, Chip Childers <ch...@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
>
>>
>> Best,
>>
>> jzb
>> --
>> Joe Brockmeier
>> http://dissociatedpress.net/
>> Twitter: @jzb
>>
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Chip Childers <ch...@sungard.com>.
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
>
Re: [DOCS][DISCUSS]Documentation for 4.1
Posted by Joe Brockmeier <jz...@zonker.net>.
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.
> 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.
Best,
jzb
--
Joe Brockmeier
http://dissociatedpress.net/
Twitter: @jzb