[AFSCS40] Release status for CS 4.0

[Alex Huang <Al...@citrix.com>]

Hi All,

I've been reminded that I've neglected to update the community on the current status for CloudStack 4.0.  I apologize for that oversight.  From now til the actual release, I will give a daily update on the status.  If you feel anything is missing, please let me know and I'll try to include them on the next update.

Summary
As of 9/24/2012, CloudStack 4.0 release has past code freeze stage (over three weeks ago).  A source code branch has been forked and is called 4.0.  Nightly build is running on Jenkins on the 4.0 build.

Feature List
There are two features that missed the 4.0 release.  Auto-Scaling and Brocade Plugin.  Both are due to having significant code changes due past the code freeze date.

Code Readiness
- There are ~5 code related reviews on the review board scheduled for 4.0.  Most of them are waiting for review and commit.
- There are <10 bugs on Jira for the first cut of the release.
- Upgrade from previous versions is currently being worked on.  Scheduled to be done by the end of the week.

License Readiness
- Majority of the VM configuration issues have been resolved.  There is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
- Technology export issues are still be worked on by David Nalley and AFS legal.  This may be a blocking issue.
- Licenses need auditing.

Doc Readiness
The current plan for docs is to write an INSTALL.TXT to give instructions on how to install from source.  All docs will be generated to a living document that continues to improve past the release.  The link to this living document is to be determined.

TODO:  Docs need help on the new features in the 4.0 release.  Specifically we need help with Niciria Integration and Caringo documentation.  

QA Status
QA is proceeding through the test cycle.  It is currently at 45% of completion.  The number of bugs generated from the tests have been minimum so the quality of the release currently looks pretty good.

Release Plan
- The current plan is for QA to complete its test cycle between 9/26-9/28. 
- When QA decides the test cycle is read, we will cut a RC1 release.
- We are currently pushing to clear bugs generated from the test cycle asap.
- After all P1 and P2 bugs are cleared, 4.0 release will be submitted for approval to announce.

--Alex

RE: [AFSCS40] Release status for CS 4.0

[Radhika Puthiyetath <ra...@citrix.com>]

Thanks Hugo. I shall get in touch with you off list.

Meanwhile, can you please share the link to the wiki.

Regards
-Radhika

-----Original Message-----
From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com] 
Sent: Sunday, September 30, 2012 4:05 AM
To: <cl...@incubator.apache.org>
Cc: Alex Huang; cloudstack-dev@incubator.apache.org; Jessica Tomechak
Subject: Re: [AFSCS40] Release status for CS 4.0

Heya,

I'm the contact for the Nicira integration stuff. There is some documentation on the wiki, but not enough. I'll try to work on it next week, if i have some time for it.

Cheers,

Hugo

Verstuurd vanaf mijn iPad

Op 26 sep. 2012 om 21:52 heeft "Radhika Puthiyetath" <ra...@citrix.com> het volgende geschreven:

> Hi Alex and the community,
> 
> Please let me know the contact point to work on the following feature documentation:
> 
> -Niciria Integration
> 
> -Caringo
> 
> I assume that nobody has signed up yet to work on these feature. I can take them up as a priority and complete at the earliest.
> 
> Regards
> -Radhika
> 
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Wednesday, September 26, 2012 11:52 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> I took off the users mailing list.
> 
> Yes.  Just make sure you do it before the next release (date TBD).  4.0 will be delivered on the 4.0 branch so Edison is cherry-picking things over right now so it is okay to start your work of merging into master.
> 
> --Alex
> 
>> -----Original Message-----
>> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam@citrix.com]
>> Sent: Wednesday, September 26, 2012 8:25 AM
>> To: cloudstack-dev@incubator.apache.org; cloudstack- 
>> users@incubator.apache.org
>> Subject: RE: [AFSCS40] Release status for CS 4.0
>> 
>> Hi Alex,
>> 
>> All the checkins are currently going to *autoscale* branch.
>> I have to generate 4 more reviews and then it will done.
>> After that, my plan is to rebase autoscale branch against master 
>> (with proper unit testing) and send a request for merge. Is this fine?
>> 
>> Thanks,
>> Vijay V.
>> 
>>> -----Original Message-----
>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>> Sent: Wednesday, September 26, 2012 12:39 AM
>>> To: cloudstack-dev@incubator.apache.org; cloudstack- 
>>> users@incubator.apache.org
>>> Subject: RE: [AFSCS40] Release status for CS 4.0
>>> 
>>> Ram,
>>> 
>>> I see a lot of recent checkins on autoscaling so if code is 
>>> completely checked into master, it should go into 4.1 automatically.
>>> 
>>> --Alex
>>> 
>>>> -----Original Message-----
>>>> From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
>>>> Sent: Monday, September 24, 2012 10:48 PM
>>>> To: cloudstack-users@incubator.apache.org; cloudstack- 
>>>> dev@incubator.apache.org
>>>> Subject: RE: [AFSCS40] Release status for CS 4.0
>>>> 
>>>> Alex,
>>>> 
>>>> For AutoScaling is there a process we should follow to bring the 
>>>> feature into
>>>> 4.1 release apart from the usual reviews/unit-tests?
>>>> 
>>>> Thanks,
>>>> Ram
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>>> Sent: 25 September 2012 07:57
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Cc: cloudstack-users@incubator.apache.org
>>>>> Subject: [AFSCS40] Release status for CS 4.0
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> I've been reminded that I've neglected to update the community on 
>>>>> the current status for CloudStack 4.0.  I apologize for that oversight.
>>>>> From now til the actual release, I will give a daily update on the 
>>>>> status.  If you feel anything is missing, please let me know and 
>>>>> I'll try to include them on the next update.
>>>>> 
>>>>> Summary
>>>>> As of 9/24/2012, CloudStack 4.0 release has past code freeze stage 
>>>>> (over three weeks ago).  A source code branch has been forked and 
>>>>> is called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
>>>>> 
>>>>> Feature List
>>>>> There are two features that missed the 4.0 release.  
>>>>> Auto-Scaling and Brocade Plugin.  Both are due to having 
>>>>> significant code changes due past the code freeze date.
>>>>> 
>>>>> Code Readiness
>>>>> - There are ~5 code related reviews on the review board scheduled 
>>>>> for 4.0.  Most of them are waiting for review and commit.
>>>>> - There are <10 bugs on Jira for the first cut of the release.
>>>>> - Upgrade from previous versions is currently being worked on.
>>>>> Scheduled to be done by the end of the week.
>>>>> 
>>>>> License Readiness
>>>>> - Majority of the VM configuration issues have been resolved.
>>>>> There is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>>>>> - Technology export issues are still be worked on by David Nalley 
>>>>> and AFS legal.  This may be a blocking issue.
>>>>> - Licenses need auditing.
>>>>> 
>>>>> Doc Readiness
>>>>> The current plan for docs is to write an INSTALL.TXT to give 
>>>>> instructions on how to install from source.  All docs will be 
>>>>> generated to a living document that continues to improve past the 
>>>>> release.  The link to this living document is to be determined.
>>>>> 
>>>>> TODO:  Docs need help on the new features in the 4.0 release.
>>>>> Specifically we need help with Niciria Integration and Caringo 
>>>>> documentation.
>>>>> 
>>>>> QA Status
>>>>> QA is proceeding through the test cycle.  It is currently at 45% 
>>>>> of completion.  The number of bugs generated from the tests have 
>>>>> been minimum so the quality of the release currently looks pretty good.
>>>>> 
>>>>> Release Plan
>>>>> - The current plan is for QA to complete its test cycle between
>>>>> 9/26- 9/28.
>>>>> - When QA decides the test cycle is read, we will cut a RC1 release.
>>>>> - We are currently pushing to clear bugs generated from the test 
>>>>> cycle asap.
>>>>> - After all P1 and P2 bugs are cleared, 4.0 release will be 
>>>>> submitted for approval to announce.
>>>>> 
>>>>> --Alex
> 

Re: [AFSCS40] Release status for CS 4.0

[Hugo Trippaers <HT...@schubergphilis.com>]

Heya,

I'm the contact for the Nicira integration stuff. There is some documentation on the wiki, but not enough. I'll try to work on it next week, if i have some time for it.

Cheers,

Hugo

Verstuurd vanaf mijn iPad

Op 26 sep. 2012 om 21:52 heeft "Radhika Puthiyetath" <ra...@citrix.com> het volgende geschreven:

> Hi Alex and the community,
> 
> Please let me know the contact point to work on the following feature documentation:
> 
> -Niciria Integration
> 
> -Caringo
> 
> I assume that nobody has signed up yet to work on these feature. I can take them up as a priority and complete at the earliest.
> 
> Regards
> -Radhika
> 
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com] 
> Sent: Wednesday, September 26, 2012 11:52 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> I took off the users mailing list.
> 
> Yes.  Just make sure you do it before the next release (date TBD).  4.0 will be delivered on the 4.0 branch so Edison is cherry-picking things over right now so it is okay to start your work of merging into master.
> 
> --Alex
> 
>> -----Original Message-----
>> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam@citrix.com]
>> Sent: Wednesday, September 26, 2012 8:25 AM
>> To: cloudstack-dev@incubator.apache.org; cloudstack- 
>> users@incubator.apache.org
>> Subject: RE: [AFSCS40] Release status for CS 4.0
>> 
>> Hi Alex,
>> 
>> All the checkins are currently going to *autoscale* branch.
>> I have to generate 4 more reviews and then it will done.
>> After that, my plan is to rebase autoscale branch against master (with 
>> proper unit testing) and send a request for merge. Is this fine?
>> 
>> Thanks,
>> Vijay V.
>> 
>>> -----Original Message-----
>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>> Sent: Wednesday, September 26, 2012 12:39 AM
>>> To: cloudstack-dev@incubator.apache.org; cloudstack- 
>>> users@incubator.apache.org
>>> Subject: RE: [AFSCS40] Release status for CS 4.0
>>> 
>>> Ram,
>>> 
>>> I see a lot of recent checkins on autoscaling so if code is 
>>> completely checked into master, it should go into 4.1 automatically.
>>> 
>>> --Alex
>>> 
>>>> -----Original Message-----
>>>> From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
>>>> Sent: Monday, September 24, 2012 10:48 PM
>>>> To: cloudstack-users@incubator.apache.org; cloudstack- 
>>>> dev@incubator.apache.org
>>>> Subject: RE: [AFSCS40] Release status for CS 4.0
>>>> 
>>>> Alex,
>>>> 
>>>> For AutoScaling is there a process we should follow to bring the 
>>>> feature into
>>>> 4.1 release apart from the usual reviews/unit-tests?
>>>> 
>>>> Thanks,
>>>> Ram
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>>> Sent: 25 September 2012 07:57
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Cc: cloudstack-users@incubator.apache.org
>>>>> Subject: [AFSCS40] Release status for CS 4.0
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> I've been reminded that I've neglected to update the community 
>>>>> on the current status for CloudStack 4.0.  I apologize for that oversight.
>>>>> From now til the actual release, I will give a daily update on 
>>>>> the status.  If you feel anything is missing, please let me know 
>>>>> and I'll try to include them on the next update.
>>>>> 
>>>>> Summary
>>>>> As of 9/24/2012, CloudStack 4.0 release has past code freeze 
>>>>> stage (over three weeks ago).  A source code branch has been 
>>>>> forked and is called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
>>>>> 
>>>>> Feature List
>>>>> There are two features that missed the 4.0 release.  
>>>>> Auto-Scaling and Brocade Plugin.  Both are due to having 
>>>>> significant code changes due past the code freeze date.
>>>>> 
>>>>> Code Readiness
>>>>> - There are ~5 code related reviews on the review board 
>>>>> scheduled for 4.0.  Most of them are waiting for review and commit.
>>>>> - There are <10 bugs on Jira for the first cut of the release.
>>>>> - Upgrade from previous versions is currently being worked on.
>>>>> Scheduled to be done by the end of the week.
>>>>> 
>>>>> License Readiness
>>>>> - Majority of the VM configuration issues have been resolved.
>>>>> There is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>>>>> - Technology export issues are still be worked on by David 
>>>>> Nalley and AFS legal.  This may be a blocking issue.
>>>>> - Licenses need auditing.
>>>>> 
>>>>> Doc Readiness
>>>>> The current plan for docs is to write an INSTALL.TXT to give 
>>>>> instructions on how to install from source.  All docs will be 
>>>>> generated to a living document that continues to improve past 
>>>>> the release.  The link to this living document is to be determined.
>>>>> 
>>>>> TODO:  Docs need help on the new features in the 4.0 release.
>>>>> Specifically we need help with Niciria Integration and Caringo 
>>>>> documentation.
>>>>> 
>>>>> QA Status
>>>>> QA is proceeding through the test cycle.  It is currently at 45% 
>>>>> of completion.  The number of bugs generated from the tests have 
>>>>> been minimum so the quality of the release currently looks pretty good.
>>>>> 
>>>>> Release Plan
>>>>> - The current plan is for QA to complete its test cycle between
>>>>> 9/26- 9/28.
>>>>> - When QA decides the test cycle is read, we will cut a RC1 release.
>>>>> - We are currently pushing to clear bugs generated from the test 
>>>>> cycle asap.
>>>>> - After all P1 and P2 bugs are cleared, 4.0 release will be 
>>>>> submitted for approval to announce.
>>>>> 
>>>>> --Alex
> 

RE: [AFSCS40] Release status for CS 4.0

[Radhika Puthiyetath <ra...@citrix.com>]

Hi Alex and the community,

Please let me know the contact point to work on the following feature documentation:

-Niciria Integration

-Caringo

I assume that nobody has signed up yet to work on these feature. I can take them up as a priority and complete at the earliest.

Regards
-Radhika

-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@citrix.com] 
Sent: Wednesday, September 26, 2012 11:52 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [AFSCS40] Release status for CS 4.0

I took off the users mailing list.

Yes.  Just make sure you do it before the next release (date TBD).  4.0 will be delivered on the 4.0 branch so Edison is cherry-picking things over right now so it is okay to start your work of merging into master.

--Alex

> -----Original Message-----
> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam@citrix.com]
> Sent: Wednesday, September 26, 2012 8:25 AM
> To: cloudstack-dev@incubator.apache.org; cloudstack- 
> users@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> Hi Alex,
> 
> All the checkins are currently going to *autoscale* branch.
> I have to generate 4 more reviews and then it will done.
> After that, my plan is to rebase autoscale branch against master (with 
> proper unit testing) and send a request for merge. Is this fine?
> 
> Thanks,
> Vijay V.
> 
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: Wednesday, September 26, 2012 12:39 AM
> > To: cloudstack-dev@incubator.apache.org; cloudstack- 
> > users@incubator.apache.org
> > Subject: RE: [AFSCS40] Release status for CS 4.0
> >
> > Ram,
> >
> > I see a lot of recent checkins on autoscaling so if code is 
> > completely checked into master, it should go into 4.1 automatically.
> >
> > --Alex
> >
> > > -----Original Message-----
> > > From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
> > > Sent: Monday, September 24, 2012 10:48 PM
> > > To: cloudstack-users@incubator.apache.org; cloudstack- 
> > > dev@incubator.apache.org
> > > Subject: RE: [AFSCS40] Release status for CS 4.0
> > >
> > > Alex,
> > >
> > > For AutoScaling is there a process we should follow to bring the 
> > > feature into
> > > 4.1 release apart from the usual reviews/unit-tests?
> > >
> > > Thanks,
> > > Ram
> > >
> > >
> > > > -----Original Message-----
> > > > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > > > Sent: 25 September 2012 07:57
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: cloudstack-users@incubator.apache.org
> > > > Subject: [AFSCS40] Release status for CS 4.0
> > > >
> > > > Hi All,
> > > >
> > > > I've been reminded that I've neglected to update the community 
> > > > on the current status for CloudStack 4.0.  I apologize for that oversight.
> > > > From now til the actual release, I will give a daily update on 
> > > > the status.  If you feel anything is missing, please let me know 
> > > > and I'll try to include them on the next update.
> > > >
> > > > Summary
> > > > As of 9/24/2012, CloudStack 4.0 release has past code freeze 
> > > > stage (over three weeks ago).  A source code branch has been 
> > > > forked and is called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> > > >
> > > > Feature List
> > > > There are two features that missed the 4.0 release.  
> > > > Auto-Scaling and Brocade Plugin.  Both are due to having 
> > > > significant code changes due past the code freeze date.
> > > >
> > > > Code Readiness
> > > > - There are ~5 code related reviews on the review board 
> > > > scheduled for 4.0.  Most of them are waiting for review and commit.
> > > > - There are <10 bugs on Jira for the first cut of the release.
> > > > - Upgrade from previous versions is currently being worked on.
> > > > Scheduled to be done by the end of the week.
> > > >
> > > > License Readiness
> > > > - Majority of the VM configuration issues have been resolved.
> > > > There is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > > > - Technology export issues are still be worked on by David 
> > > > Nalley and AFS legal.  This may be a blocking issue.
> > > > - Licenses need auditing.
> > > >
> > > > Doc Readiness
> > > > The current plan for docs is to write an INSTALL.TXT to give 
> > > > instructions on how to install from source.  All docs will be 
> > > > generated to a living document that continues to improve past 
> > > > the release.  The link to this living document is to be determined.
> > > >
> > > > TODO:  Docs need help on the new features in the 4.0 release.
> > > > Specifically we need help with Niciria Integration and Caringo 
> > > > documentation.
> > > >
> > > > QA Status
> > > > QA is proceeding through the test cycle.  It is currently at 45% 
> > > > of completion.  The number of bugs generated from the tests have 
> > > > been minimum so the quality of the release currently looks pretty good.
> > > >
> > > > Release Plan
> > > > - The current plan is for QA to complete its test cycle between
> > > > 9/26- 9/28.
> > > > - When QA decides the test cycle is read, we will cut a RC1 release.
> > > > - We are currently pushing to clear bugs generated from the test 
> > > > cycle asap.
> > > > - After all P1 and P2 bugs are cleared, 4.0 release will be 
> > > > submitted for approval to announce.
> > > >
> > > > --Alex

RE: [AFSCS40] Release status for CS 4.0

[Alex Huang <Al...@citrix.com>]

I took off the users mailing list.

Yes.  Just make sure you do it before the next release (date TBD).  4.0 will be delivered on the 4.0 branch so Edison is cherry-picking things over right now so it is okay to start your work of merging into master.

--Alex

> -----Original Message-----
> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam@citrix.com]
> Sent: Wednesday, September 26, 2012 8:25 AM
> To: cloudstack-dev@incubator.apache.org; cloudstack-
> users@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> Hi Alex,
> 
> All the checkins are currently going to *autoscale* branch.
> I have to generate 4 more reviews and then it will done.
> After that, my plan is to rebase autoscale branch against master (with proper
> unit testing) and send a request for merge. Is this fine?
> 
> Thanks,
> Vijay V.
> 
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: Wednesday, September 26, 2012 12:39 AM
> > To: cloudstack-dev@incubator.apache.org; cloudstack-
> > users@incubator.apache.org
> > Subject: RE: [AFSCS40] Release status for CS 4.0
> >
> > Ram,
> >
> > I see a lot of recent checkins on autoscaling so if code is completely
> > checked into master, it should go into 4.1 automatically.
> >
> > --Alex
> >
> > > -----Original Message-----
> > > From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
> > > Sent: Monday, September 24, 2012 10:48 PM
> > > To: cloudstack-users@incubator.apache.org; cloudstack-
> > > dev@incubator.apache.org
> > > Subject: RE: [AFSCS40] Release status for CS 4.0
> > >
> > > Alex,
> > >
> > > For AutoScaling is there a process we should follow to bring the
> > > feature into
> > > 4.1 release apart from the usual reviews/unit-tests?
> > >
> > > Thanks,
> > > Ram
> > >
> > >
> > > > -----Original Message-----
> > > > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > > > Sent: 25 September 2012 07:57
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: cloudstack-users@incubator.apache.org
> > > > Subject: [AFSCS40] Release status for CS 4.0
> > > >
> > > > Hi All,
> > > >
> > > > I've been reminded that I've neglected to update the community on
> > > > the current status for CloudStack 4.0.  I apologize for that oversight.
> > > > From now til the actual release, I will give a daily update on the
> > > > status.  If you feel anything is missing, please let me know and
> > > > I'll try to include them on the next update.
> > > >
> > > > Summary
> > > > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> > > > (over three weeks ago).  A source code branch has been forked and
> > > > is called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> > > >
> > > > Feature List
> > > > There are two features that missed the 4.0 release.  Auto-Scaling
> > > > and Brocade Plugin.  Both are due to having significant code
> > > > changes due past the code freeze date.
> > > >
> > > > Code Readiness
> > > > - There are ~5 code related reviews on the review board scheduled
> > > > for 4.0.  Most of them are waiting for review and commit.
> > > > - There are <10 bugs on Jira for the first cut of the release.
> > > > - Upgrade from previous versions is currently being worked on.
> > > > Scheduled to be done by the end of the week.
> > > >
> > > > License Readiness
> > > > - Majority of the VM configuration issues have been resolved.
> > > > There is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > > > - Technology export issues are still be worked on by David Nalley
> > > > and AFS legal.  This may be a blocking issue.
> > > > - Licenses need auditing.
> > > >
> > > > Doc Readiness
> > > > The current plan for docs is to write an INSTALL.TXT to give
> > > > instructions on how to install from source.  All docs will be
> > > > generated to a living document that continues to improve past the
> > > > release.  The link to this living document is to be determined.
> > > >
> > > > TODO:  Docs need help on the new features in the 4.0 release.
> > > > Specifically we need help with Niciria Integration and Caringo
> > > > documentation.
> > > >
> > > > QA Status
> > > > QA is proceeding through the test cycle.  It is currently at 45%
> > > > of completion.  The number of bugs generated from the tests have
> > > > been minimum so the quality of the release currently looks pretty good.
> > > >
> > > > Release Plan
> > > > - The current plan is for QA to complete its test cycle between
> > > > 9/26- 9/28.
> > > > - When QA decides the test cycle is read, we will cut a RC1 release.
> > > > - We are currently pushing to clear bugs generated from the test
> > > > cycle asap.
> > > > - After all P1 and P2 bugs are cleared, 4.0 release will be
> > > > submitted for approval to announce.
> > > >
> > > > --Alex

RE: [AFSCS40] Release status for CS 4.0

[Vijay Venkatachalam <Vi...@citrix.com>]

Hi Alex,

All the checkins are currently going to *autoscale* branch. 
I have to generate 4 more reviews and then it will done.
After that, my plan is to rebase autoscale branch against master (with proper 
unit testing) and send a request for merge. Is this fine?

Thanks,
Vijay V.

> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Wednesday, September 26, 2012 12:39 AM
> To: cloudstack-dev@incubator.apache.org; cloudstack-
> users@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> Ram,
> 
> I see a lot of recent checkins on autoscaling so if code is completely checked
> into master, it should go into 4.1 automatically.
> 
> --Alex
> 
> > -----Original Message-----
> > From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
> > Sent: Monday, September 24, 2012 10:48 PM
> > To: cloudstack-users@incubator.apache.org; cloudstack-
> > dev@incubator.apache.org
> > Subject: RE: [AFSCS40] Release status for CS 4.0
> >
> > Alex,
> >
> > For AutoScaling is there a process we should follow to bring the
> > feature into
> > 4.1 release apart from the usual reviews/unit-tests?
> >
> > Thanks,
> > Ram
> >
> >
> > > -----Original Message-----
> > > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > > Sent: 25 September 2012 07:57
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: cloudstack-users@incubator.apache.org
> > > Subject: [AFSCS40] Release status for CS 4.0
> > >
> > > Hi All,
> > >
> > > I've been reminded that I've neglected to update the community on
> > > the current status for CloudStack 4.0.  I apologize for that oversight.
> > > From now til the actual release, I will give a daily update on the
> > > status.  If you feel anything is missing, please let me know and
> > > I'll try to include them on the next update.
> > >
> > > Summary
> > > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> > > (over three weeks ago).  A source code branch has been forked and is
> > > called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> > >
> > > Feature List
> > > There are two features that missed the 4.0 release.  Auto-Scaling
> > > and Brocade Plugin.  Both are due to having significant code changes
> > > due past the code freeze date.
> > >
> > > Code Readiness
> > > - There are ~5 code related reviews on the review board scheduled
> > > for 4.0.  Most of them are waiting for review and commit.
> > > - There are <10 bugs on Jira for the first cut of the release.
> > > - Upgrade from previous versions is currently being worked on.
> > > Scheduled to be done by the end of the week.
> > >
> > > License Readiness
> > > - Majority of the VM configuration issues have been resolved.  There
> > > is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > > - Technology export issues are still be worked on by David Nalley
> > > and AFS legal.  This may be a blocking issue.
> > > - Licenses need auditing.
> > >
> > > Doc Readiness
> > > The current plan for docs is to write an INSTALL.TXT to give
> > > instructions on how to install from source.  All docs will be
> > > generated to a living document that continues to improve past the
> > > release.  The link to this living document is to be determined.
> > >
> > > TODO:  Docs need help on the new features in the 4.0 release.
> > > Specifically we need help with Niciria Integration and Caringo
> > > documentation.
> > >
> > > QA Status
> > > QA is proceeding through the test cycle.  It is currently at 45% of
> > > completion.  The number of bugs generated from the tests have been
> > > minimum so the quality of the release currently looks pretty good.
> > >
> > > Release Plan
> > > - The current plan is for QA to complete its test cycle between
> > > 9/26- 9/28.
> > > - When QA decides the test cycle is read, we will cut a RC1 release.
> > > - We are currently pushing to clear bugs generated from the test
> > > cycle asap.
> > > - After all P1 and P2 bugs are cleared, 4.0 release will be
> > > submitted for approval to announce.
> > >
> > > --Alex

RE: [AFSCS40] Release status for CS 4.0

[Vijay Venkatachalam <Vi...@citrix.com>]

Hi Alex,

All the checkins are currently going to *autoscale* branch. 
I have to generate 4 more reviews and then it will done.
After that, my plan is to rebase autoscale branch against master (with proper 
unit testing) and send a request for merge. Is this fine?

Thanks,
Vijay V.

> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Wednesday, September 26, 2012 12:39 AM
> To: cloudstack-dev@incubator.apache.org; cloudstack-
> users@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> Ram,
> 
> I see a lot of recent checkins on autoscaling so if code is completely checked
> into master, it should go into 4.1 automatically.
> 
> --Alex
> 
> > -----Original Message-----
> > From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
> > Sent: Monday, September 24, 2012 10:48 PM
> > To: cloudstack-users@incubator.apache.org; cloudstack-
> > dev@incubator.apache.org
> > Subject: RE: [AFSCS40] Release status for CS 4.0
> >
> > Alex,
> >
> > For AutoScaling is there a process we should follow to bring the
> > feature into
> > 4.1 release apart from the usual reviews/unit-tests?
> >
> > Thanks,
> > Ram
> >
> >
> > > -----Original Message-----
> > > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > > Sent: 25 September 2012 07:57
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: cloudstack-users@incubator.apache.org
> > > Subject: [AFSCS40] Release status for CS 4.0
> > >
> > > Hi All,
> > >
> > > I've been reminded that I've neglected to update the community on
> > > the current status for CloudStack 4.0.  I apologize for that oversight.
> > > From now til the actual release, I will give a daily update on the
> > > status.  If you feel anything is missing, please let me know and
> > > I'll try to include them on the next update.
> > >
> > > Summary
> > > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> > > (over three weeks ago).  A source code branch has been forked and is
> > > called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> > >
> > > Feature List
> > > There are two features that missed the 4.0 release.  Auto-Scaling
> > > and Brocade Plugin.  Both are due to having significant code changes
> > > due past the code freeze date.
> > >
> > > Code Readiness
> > > - There are ~5 code related reviews on the review board scheduled
> > > for 4.0.  Most of them are waiting for review and commit.
> > > - There are <10 bugs on Jira for the first cut of the release.
> > > - Upgrade from previous versions is currently being worked on.
> > > Scheduled to be done by the end of the week.
> > >
> > > License Readiness
> > > - Majority of the VM configuration issues have been resolved.  There
> > > is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > > - Technology export issues are still be worked on by David Nalley
> > > and AFS legal.  This may be a blocking issue.
> > > - Licenses need auditing.
> > >
> > > Doc Readiness
> > > The current plan for docs is to write an INSTALL.TXT to give
> > > instructions on how to install from source.  All docs will be
> > > generated to a living document that continues to improve past the
> > > release.  The link to this living document is to be determined.
> > >
> > > TODO:  Docs need help on the new features in the 4.0 release.
> > > Specifically we need help with Niciria Integration and Caringo
> > > documentation.
> > >
> > > QA Status
> > > QA is proceeding through the test cycle.  It is currently at 45% of
> > > completion.  The number of bugs generated from the tests have been
> > > minimum so the quality of the release currently looks pretty good.
> > >
> > > Release Plan
> > > - The current plan is for QA to complete its test cycle between
> > > 9/26- 9/28.
> > > - When QA decides the test cycle is read, we will cut a RC1 release.
> > > - We are currently pushing to clear bugs generated from the test
> > > cycle asap.
> > > - After all P1 and P2 bugs are cleared, 4.0 release will be
> > > submitted for approval to announce.
> > >
> > > --Alex

RE: [AFSCS40] Release status for CS 4.0

[Alex Huang <Al...@citrix.com>]

Ram,

I see a lot of recent checkins on autoscaling so if code is completely checked into master, it should go into 4.1 automatically.

--Alex

> -----Original Message-----
> From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
> Sent: Monday, September 24, 2012 10:48 PM
> To: cloudstack-users@incubator.apache.org; cloudstack-
> dev@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> Alex,
> 
> For AutoScaling is there a process we should follow to bring the feature into
> 4.1 release apart from the usual reviews/unit-tests?
> 
> Thanks,
> Ram
> 
> 
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: 25 September 2012 07:57
> > To: cloudstack-dev@incubator.apache.org
> > Cc: cloudstack-users@incubator.apache.org
> > Subject: [AFSCS40] Release status for CS 4.0
> >
> > Hi All,
> >
> > I've been reminded that I've neglected to update the community on the
> > current status for CloudStack 4.0.  I apologize for that oversight.
> > From now til the actual release, I will give a daily update on the
> > status.  If you feel anything is missing, please let me know and I'll
> > try to include them on the next update.
> >
> > Summary
> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> > (over three weeks ago).  A source code branch has been forked and is
> > called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> >
> > Feature List
> > There are two features that missed the 4.0 release.  Auto-Scaling and
> > Brocade Plugin.  Both are due to having significant code changes due
> > past the code freeze date.
> >
> > Code Readiness
> > - There are ~5 code related reviews on the review board scheduled for
> > 4.0.  Most of them are waiting for review and commit.
> > - There are <10 bugs on Jira for the first cut of the release.
> > - Upgrade from previous versions is currently being worked on.
> > Scheduled to be done by the end of the week.
> >
> > License Readiness
> > - Majority of the VM configuration issues have been resolved.  There
> > is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > - Technology export issues are still be worked on by David Nalley and
> > AFS legal.  This may be a blocking issue.
> > - Licenses need auditing.
> >
> > Doc Readiness
> > The current plan for docs is to write an INSTALL.TXT to give
> > instructions on how to install from source.  All docs will be
> > generated to a living document that continues to improve past the
> > release.  The link to this living document is to be determined.
> >
> > TODO:  Docs need help on the new features in the 4.0 release.
> > Specifically we need help with Niciria Integration and Caringo
> > documentation.
> >
> > QA Status
> > QA is proceeding through the test cycle.  It is currently at 45% of
> > completion.  The number of bugs generated from the tests have been
> > minimum so the quality of the release currently looks pretty good.
> >
> > Release Plan
> > - The current plan is for QA to complete its test cycle between 9/26-
> > 9/28.
> > - When QA decides the test cycle is read, we will cut a RC1 release.
> > - We are currently pushing to clear bugs generated from the test cycle
> > asap.
> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
> > for approval to announce.
> >
> > --Alex

RE: [AFSCS40] Release status for CS 4.0

[Alex Huang <Al...@citrix.com>]

Ram,

I see a lot of recent checkins on autoscaling so if code is completely checked into master, it should go into 4.1 automatically.

--Alex

> -----Original Message-----
> From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
> Sent: Monday, September 24, 2012 10:48 PM
> To: cloudstack-users@incubator.apache.org; cloudstack-
> dev@incubator.apache.org
> Subject: RE: [AFSCS40] Release status for CS 4.0
> 
> Alex,
> 
> For AutoScaling is there a process we should follow to bring the feature into
> 4.1 release apart from the usual reviews/unit-tests?
> 
> Thanks,
> Ram
> 
> 
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: 25 September 2012 07:57
> > To: cloudstack-dev@incubator.apache.org
> > Cc: cloudstack-users@incubator.apache.org
> > Subject: [AFSCS40] Release status for CS 4.0
> >
> > Hi All,
> >
> > I've been reminded that I've neglected to update the community on the
> > current status for CloudStack 4.0.  I apologize for that oversight.
> > From now til the actual release, I will give a daily update on the
> > status.  If you feel anything is missing, please let me know and I'll
> > try to include them on the next update.
> >
> > Summary
> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> > (over three weeks ago).  A source code branch has been forked and is
> > called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> >
> > Feature List
> > There are two features that missed the 4.0 release.  Auto-Scaling and
> > Brocade Plugin.  Both are due to having significant code changes due
> > past the code freeze date.
> >
> > Code Readiness
> > - There are ~5 code related reviews on the review board scheduled for
> > 4.0.  Most of them are waiting for review and commit.
> > - There are <10 bugs on Jira for the first cut of the release.
> > - Upgrade from previous versions is currently being worked on.
> > Scheduled to be done by the end of the week.
> >
> > License Readiness
> > - Majority of the VM configuration issues have been resolved.  There
> > is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > - Technology export issues are still be worked on by David Nalley and
> > AFS legal.  This may be a blocking issue.
> > - Licenses need auditing.
> >
> > Doc Readiness
> > The current plan for docs is to write an INSTALL.TXT to give
> > instructions on how to install from source.  All docs will be
> > generated to a living document that continues to improve past the
> > release.  The link to this living document is to be determined.
> >
> > TODO:  Docs need help on the new features in the 4.0 release.
> > Specifically we need help with Niciria Integration and Caringo
> > documentation.
> >
> > QA Status
> > QA is proceeding through the test cycle.  It is currently at 45% of
> > completion.  The number of bugs generated from the tests have been
> > minimum so the quality of the release currently looks pretty good.
> >
> > Release Plan
> > - The current plan is for QA to complete its test cycle between 9/26-
> > 9/28.
> > - When QA decides the test cycle is read, we will cut a RC1 release.
> > - We are currently pushing to clear bugs generated from the test cycle
> > asap.
> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
> > for approval to announce.
> >
> > --Alex

RE: [AFSCS40] Release status for CS 4.0

[Ram Ganesh <Ra...@citrix.com>]

Alex,

For AutoScaling is there a process we should follow to bring the feature into 4.1 release apart from the usual reviews/unit-tests?

Thanks,
Ram


> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: 25 September 2012 07:57
> To: cloudstack-dev@incubator.apache.org
> Cc: cloudstack-users@incubator.apache.org
> Subject: [AFSCS40] Release status for CS 4.0
> 
> Hi All,
> 
> I've been reminded that I've neglected to update the community on the
> current status for CloudStack 4.0.  I apologize for that oversight.
> From now til the actual release, I will give a daily update on the
> status.  If you feel anything is missing, please let me know and I'll
> try to include them on the next update.
> 
> Summary
> As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> (over three weeks ago).  A source code branch has been forked and is
> called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> 
> Feature List
> There are two features that missed the 4.0 release.  Auto-Scaling and
> Brocade Plugin.  Both are due to having significant code changes due
> past the code freeze date.
> 
> Code Readiness
> - There are ~5 code related reviews on the review board scheduled for
> 4.0.  Most of them are waiting for review and commit.
> - There are <10 bugs on Jira for the first cut of the release.
> - Upgrade from previous versions is currently being worked on.
> Scheduled to be done by the end of the week.
> 
> License Readiness
> - Majority of the VM configuration issues have been resolved.  There is
> one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> - Technology export issues are still be worked on by David Nalley and
> AFS legal.  This may be a blocking issue.
> - Licenses need auditing.
> 
> Doc Readiness
> The current plan for docs is to write an INSTALL.TXT to give
> instructions on how to install from source.  All docs will be generated
> to a living document that continues to improve past the release.  The
> link to this living document is to be determined.
> 
> TODO:  Docs need help on the new features in the 4.0 release.
> Specifically we need help with Niciria Integration and Caringo
> documentation.
> 
> QA Status
> QA is proceeding through the test cycle.  It is currently at 45% of
> completion.  The number of bugs generated from the tests have been
> minimum so the quality of the release currently looks pretty good.
> 
> Release Plan
> - The current plan is for QA to complete its test cycle between 9/26-
> 9/28.
> - When QA decides the test cycle is read, we will cut a RC1 release.
> - We are currently pushing to clear bugs generated from the test cycle
> asap.
> - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
> for approval to announce.
> 
> --Alex

RE: [AFSCS40] Release status for CS 4.0

[Ram Ganesh <Ra...@citrix.com>]

Alex,

For AutoScaling is there a process we should follow to bring the feature into 4.1 release apart from the usual reviews/unit-tests?

Thanks,
Ram


> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: 25 September 2012 07:57
> To: cloudstack-dev@incubator.apache.org
> Cc: cloudstack-users@incubator.apache.org
> Subject: [AFSCS40] Release status for CS 4.0
> 
> Hi All,
> 
> I've been reminded that I've neglected to update the community on the
> current status for CloudStack 4.0.  I apologize for that oversight.
> From now til the actual release, I will give a daily update on the
> status.  If you feel anything is missing, please let me know and I'll
> try to include them on the next update.
> 
> Summary
> As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> (over three weeks ago).  A source code branch has been forked and is
> called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
> 
> Feature List
> There are two features that missed the 4.0 release.  Auto-Scaling and
> Brocade Plugin.  Both are due to having significant code changes due
> past the code freeze date.
> 
> Code Readiness
> - There are ~5 code related reviews on the review board scheduled for
> 4.0.  Most of them are waiting for review and commit.
> - There are <10 bugs on Jira for the first cut of the release.
> - Upgrade from previous versions is currently being worked on.
> Scheduled to be done by the end of the week.
> 
> License Readiness
> - Majority of the VM configuration issues have been resolved.  There is
> one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> - Technology export issues are still be worked on by David Nalley and
> AFS legal.  This may be a blocking issue.
> - Licenses need auditing.
> 
> Doc Readiness
> The current plan for docs is to write an INSTALL.TXT to give
> instructions on how to install from source.  All docs will be generated
> to a living document that continues to improve past the release.  The
> link to this living document is to be determined.
> 
> TODO:  Docs need help on the new features in the 4.0 release.
> Specifically we need help with Niciria Integration and Caringo
> documentation.
> 
> QA Status
> QA is proceeding through the test cycle.  It is currently at 45% of
> completion.  The number of bugs generated from the tests have been
> minimum so the quality of the release currently looks pretty good.
> 
> Release Plan
> - The current plan is for QA to complete its test cycle between 9/26-
> 9/28.
> - When QA decides the test cycle is read, we will cut a RC1 release.
> - We are currently pushing to clear bugs generated from the test cycle
> asap.
> - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
> for approval to announce.
> 
> --Alex

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

On Sun, Sep 30, 2012 at 7:23 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Chip,
>
> Can you point me to where you're hosting these builds?

p.a.o/~chipchilders/cloudstack/4.0 - exactly where they are supposed to go. ;-)

> We need to be super careful about the distinction between the following
> items:
>
>    - A build
>       - A source or binary package that will note be voted on
>    - A release candidate
>       - A source package that is being voted on
>    - A release
>       - A source package that has been voted on

Good reminder.

> (Please note that "build" and "release candidate" are not official ASF
> nomenclature. You could call a build a "package" or a "nightly" or a
> "tarball" or whatever it happens to be. Build kinda works for most things.
> It's a preparation of the source. And release candidate might just be
> called "the voting artefact" or what have you. It's the thing we're voting
> on for a release.)
>
> A binary package will never be anything more than a build that is prepared
> by an individual for the convenience of others. So let's just get that out
> of the way. A binary package can never graduate to anything other than a
> build.
>
> A source package can do many things though.
>
> On the one hand, as an individual, we can prepare source packages as
> snapshots, or nightlies. A committer can upload them to people.apache.org,
> and advertise them to developers. (But we must not advertise them to users
> without heavy caveating.) Generally, these are used by people working on
> the project itself, not with the project. Though, we may want to highlight
> a particular build before starting the official release process, to get
> feedback on things.
>
> If we think we're ready for a release, we can prepare a build to vote on.
> We upload this to people.apache.org, and we start a VOTE thread. At this
> point, the build becomes a release candidate. And only at this point. (Also
> note that because a release candidate must progress to a release without
> any modification, we cannot include "RC" in the version number.)

Agreed on the RC not being part of an actual release candidate's
version number, due to the nature of the voting / distribution
process.

> If the vote passes, the source package becomes a release, and we upload it
> to our dist dir and tell users about it.
>
> In this context, language like this concerns me:
>
> "each RC build should come with release notes"
>
> These are not release candidates unless we're voting on them, and they
> certainly must not come with release notes.
>
> If an individual is providing nightlies, let's call them nighties, and
> let's attach "QA notes".

+1 to calling them something besides release notes

>
> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com> wrote:
>> > Chip,
>> >
>> > In the future, we should.  If we were doing this right (which we aren't
>> today), each RC build should come with release notes about what QA has
>> found to be problems.  I think what you're putting up right now are more
>> closer to nightly unstable builds than RC builds.
>>
>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>> packaging the code only.
>>
>> We're in a weird state right now, since we won't be able to pass a
>> vote yet.  The way I see other projects doing this, is that even
>> unstable builds / source packages can be considered a release.  They
>> just get labeled something like "alpha" or whatever.  The projects do
>> vote on them though (which we're not ready for).
>>
>> I guess I'll just keep incrementing for now - so that those people
>> looking at the source package know that it's a new version (vs. Citrix
>> QA, which I believe is pulling unofficial builds from Jenkins for
>> functional testing).
>>
>> -chip
>>
>> > The good news is that the quality has been pretty good so even the
>> nightly unstable builds are good.  Today, that's mostly due to the majority
>> features in this release came from Citrix and were already tested by
>> Citrix.  For future releases, we should follow a process of QA completes
>> 100% testing and that's a RC build while there's nightly builds for people
>> who are actually developing if they're interested.
>> >
>> > --Alex
>> >
>> >> -----Original Message-----
>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >> Sent: Monday, September 24, 2012 8:14 PM
>> >> To: <cl...@incubator.apache.org>
>> >> Cc: cloudstack-dev@incubator.apache.org
>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>> >>
>> >> Alex,
>> >>
>> >> I've been cutting "RC" source code bundles, and have been numbering them
>> >> as RCx (Wednesday will be RC3).
>> >>
>> >> Do you think I should switch to a more informal scheme until we have
>> >> something to vote on officially?
>> >>
>> >> - chip
>> >>
>> >> Sent from my iPhone.
>> >>
>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
>> >>
>> >> > Hi All,
>> >> >
>> >> > I've been reminded that I've neglected to update the community on the
>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>  From now til
>> >> the actual release, I will give a daily update on the status.  If you
>> feel anything
>> >> is missing, please let me know and I'll try to include them on the next
>> update.
>> >> >
>> >> > Summary
>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>> (over
>> >> three weeks ago).  A source code branch has been forked and is called
>> 4.0.
>> >> Nightly build is running on Jenkins on the 4.0 build.
>> >> >
>> >> > Feature List
>> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
>> >> Brocade Plugin.  Both are due to having significant code changes due
>> past the
>> >> code freeze date.
>> >> >
>> >> > Code Readiness
>> >> > - There are ~5 code related reviews on the review board scheduled for
>> 4.0.
>> >> Most of them are waiting for review and commit.
>> >> > - There are <10 bugs on Jira for the first cut of the release.
>> >> > - Upgrade from previous versions is currently being worked on.
>>  Scheduled
>> >> to be done by the end of the week.
>> >> >
>> >> > License Readiness
>> >> > - Majority of the VM configuration issues have been resolved.  There
>> is one
>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> >> > - Technology export issues are still be worked on by David Nalley and
>> AFS
>> >> legal.  This may be a blocking issue.
>> >> > - Licenses need auditing.
>> >> >
>> >> > Doc Readiness
>> >> > The current plan for docs is to write an INSTALL.TXT to give
>> instructions on
>> >> how to install from source.  All docs will be generated to a living
>> document
>> >> that continues to improve past the release.  The link to this living
>> document is
>> >> to be determined.
>> >> >
>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>  Specifically
>> >> we need help with Niciria Integration and Caringo documentation.
>> >> >
>> >> > QA Status
>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>> completion.
>> >> The number of bugs generated from the tests have been minimum so the
>> >> quality of the release currently looks pretty good.
>> >> >
>> >> > Release Plan
>> >> > - The current plan is for QA to complete its test cycle between
>> 9/26-9/28.
>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>> >> > - We are currently pushing to clear bugs generated from the test
>> cycle asap.
>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
>> for
>> >> approval to announce.
>> >> >
>> >> > --Alex
>> >> >
>> >> >
>> >
>>
>
>
>
> --
> NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

cf. http://www.apache.org/foundation/glossary.html

On Sun, Sep 30, 2012 at 6:09 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Minor correction, "build" is official ASF nomenclature.
>
> "A Build is a package which is not suitable for distribution to the
> general public. They are works-in-progress, and as such the only people
> builds should be offered to are other people working on product development
> at the foundation."
>
> "Release candidate" is not, however, and is best avoided. We don't really
> do release candidates at apache, so if you use it to talk about voting
> artefacts, you risk confusing people who assume you're using the more
> common sense of the word. If something is alpha, call it alpha.
>
> On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org>wrote:
>
>> Chip,
>>
>> Can you point me to where you're hosting these builds?
>>
>> We need to be super careful about the distinction between the following
>> items:
>>
>>    - A build
>>       - A source or binary package that will note be voted on
>>    - A release candidate
>>       - A source package that is being voted on
>>    - A release
>>       - A source package that has been voted on
>>
>> (Please note that "build" and "release candidate" are not official ASF
>> nomenclature. You could call a build a "package" or a "nightly" or a
>> "tarball" or whatever it happens to be. Build kinda works for most things.
>> It's a preparation of the source. And release candidate might just be
>> called "the voting artefact" or what have you. It's the thing we're voting
>> on for a release.)
>>
>> A binary package will never be anything more than a build that is
>> prepared by an individual for the convenience of others. So let's just get
>> that out of the way. A binary package can never graduate to anything other
>> than a build.
>>
>> A source package can do many things though.
>>
>> On the one hand, as an individual, we can prepare source packages as
>> snapshots, or nightlies. A committer can upload them to people.apache.org,
>> and advertise them to developers. (But we must not advertise them to users
>> without heavy caveating.) Generally, these are used by people working on
>> the project itself, not with the project. Though, we may want to highlight
>> a particular build before starting the official release process, to get
>> feedback on things.
>>
>> If we think we're ready for a release, we can prepare a build to vote on.
>> We upload this to people.apache.org, and we start a VOTE thread. At this
>> point, the build becomes a release candidate. And only at this point. (Also
>> note that because a release candidate must progress to a release without
>> any modification, we cannot include "RC" in the version number.)
>>
>> If the vote passes, the source package becomes a release, and we upload
>> it to our dist dir and tell users about it.
>>
>> In this context, language like this concerns me:
>>
>> "each RC build should come with release notes"
>>
>> These are not release candidates unless we're voting on them, and they
>> certainly must not come with release notes.
>>
>> If an individual is providing nightlies, let's call them nighties, and
>> let's attach "QA notes".
>>
>>
>> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <chip.childers@sungard.com
>> > wrote:
>>
>>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> > Chip,
>>> >
>>> > In the future, we should.  If we were doing this right (which we
>>> aren't today), each RC build should come with release notes about what QA
>>> has found to be problems.  I think what you're putting up right now are
>>> more closer to nightly unstable builds than RC builds.
>>>
>>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>>> packaging the code only.
>>>
>>> We're in a weird state right now, since we won't be able to pass a
>>> vote yet.  The way I see other projects doing this, is that even
>>> unstable builds / source packages can be considered a release.  They
>>> just get labeled something like "alpha" or whatever.  The projects do
>>> vote on them though (which we're not ready for).
>>>
>>> I guess I'll just keep incrementing for now - so that those people
>>> looking at the source package know that it's a new version (vs. Citrix
>>> QA, which I believe is pulling unofficial builds from Jenkins for
>>> functional testing).
>>>
>>> -chip
>>>
>>> > The good news is that the quality has been pretty good so even the
>>> nightly unstable builds are good.  Today, that's mostly due to the majority
>>> features in this release came from Citrix and were already tested by
>>> Citrix.  For future releases, we should follow a process of QA completes
>>> 100% testing and that's a RC build while there's nightly builds for people
>>> who are actually developing if they're interested.
>>> >
>>> > --Alex
>>> >
>>> >> -----Original Message-----
>>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> >> Sent: Monday, September 24, 2012 8:14 PM
>>> >> To: <cl...@incubator.apache.org>
>>> >> Cc: cloudstack-dev@incubator.apache.org
>>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>>> >>
>>> >> Alex,
>>> >>
>>> >> I've been cutting "RC" source code bundles, and have been numbering
>>> them
>>> >> as RCx (Wednesday will be RC3).
>>> >>
>>> >> Do you think I should switch to a more informal scheme until we have
>>> >> something to vote on officially?
>>> >>
>>> >> - chip
>>> >>
>>> >> Sent from my iPhone.
>>> >>
>>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> >>
>>> >> > Hi All,
>>> >> >
>>> >> > I've been reminded that I've neglected to update the community on
>>> the
>>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>>  From now til
>>> >> the actual release, I will give a daily update on the status.  If you
>>> feel anything
>>> >> is missing, please let me know and I'll try to include them on the
>>> next update.
>>> >> >
>>> >> > Summary
>>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>>> (over
>>> >> three weeks ago).  A source code branch has been forked and is called
>>> 4.0.
>>> >> Nightly build is running on Jenkins on the 4.0 build.
>>> >> >
>>> >> > Feature List
>>> >> > There are two features that missed the 4.0 release.  Auto-Scaling
>>> and
>>> >> Brocade Plugin.  Both are due to having significant code changes due
>>> past the
>>> >> code freeze date.
>>> >> >
>>> >> > Code Readiness
>>> >> > - There are ~5 code related reviews on the review board scheduled
>>> for 4.0.
>>> >> Most of them are waiting for review and commit.
>>> >> > - There are <10 bugs on Jira for the first cut of the release.
>>> >> > - Upgrade from previous versions is currently being worked on.
>>>  Scheduled
>>> >> to be done by the end of the week.
>>> >> >
>>> >> > License Readiness
>>> >> > - Majority of the VM configuration issues have been resolved.
>>>  There is one
>>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>>> >> > - Technology export issues are still be worked on by David Nalley
>>> and AFS
>>> >> legal.  This may be a blocking issue.
>>> >> > - Licenses need auditing.
>>> >> >
>>> >> > Doc Readiness
>>> >> > The current plan for docs is to write an INSTALL.TXT to give
>>> instructions on
>>> >> how to install from source.  All docs will be generated to a living
>>> document
>>> >> that continues to improve past the release.  The link to this living
>>> document is
>>> >> to be determined.
>>> >> >
>>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>>  Specifically
>>> >> we need help with Niciria Integration and Caringo documentation.
>>> >> >
>>> >> > QA Status
>>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>>> completion.
>>> >> The number of bugs generated from the tests have been minimum so the
>>> >> quality of the release currently looks pretty good.
>>> >> >
>>> >> > Release Plan
>>> >> > - The current plan is for QA to complete its test cycle between
>>> 9/26-9/28.
>>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>>> >> > - We are currently pushing to clear bugs generated from the test
>>> cycle asap.
>>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>>> submitted for
>>> >> approval to announce.
>>> >> >
>>> >> > --Alex
>>> >> >
>>> >> >
>>> >
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

cf. http://www.apache.org/foundation/glossary.html

On Sun, Sep 30, 2012 at 6:09 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Minor correction, "build" is official ASF nomenclature.
>
> "A Build is a package which is not suitable for distribution to the
> general public. They are works-in-progress, and as such the only people
> builds should be offered to are other people working on product development
> at the foundation."
>
> "Release candidate" is not, however, and is best avoided. We don't really
> do release candidates at apache, so if you use it to talk about voting
> artefacts, you risk confusing people who assume you're using the more
> common sense of the word. If something is alpha, call it alpha.
>
> On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org>wrote:
>
>> Chip,
>>
>> Can you point me to where you're hosting these builds?
>>
>> We need to be super careful about the distinction between the following
>> items:
>>
>>    - A build
>>       - A source or binary package that will note be voted on
>>    - A release candidate
>>       - A source package that is being voted on
>>    - A release
>>       - A source package that has been voted on
>>
>> (Please note that "build" and "release candidate" are not official ASF
>> nomenclature. You could call a build a "package" or a "nightly" or a
>> "tarball" or whatever it happens to be. Build kinda works for most things.
>> It's a preparation of the source. And release candidate might just be
>> called "the voting artefact" or what have you. It's the thing we're voting
>> on for a release.)
>>
>> A binary package will never be anything more than a build that is
>> prepared by an individual for the convenience of others. So let's just get
>> that out of the way. A binary package can never graduate to anything other
>> than a build.
>>
>> A source package can do many things though.
>>
>> On the one hand, as an individual, we can prepare source packages as
>> snapshots, or nightlies. A committer can upload them to people.apache.org,
>> and advertise them to developers. (But we must not advertise them to users
>> without heavy caveating.) Generally, these are used by people working on
>> the project itself, not with the project. Though, we may want to highlight
>> a particular build before starting the official release process, to get
>> feedback on things.
>>
>> If we think we're ready for a release, we can prepare a build to vote on.
>> We upload this to people.apache.org, and we start a VOTE thread. At this
>> point, the build becomes a release candidate. And only at this point. (Also
>> note that because a release candidate must progress to a release without
>> any modification, we cannot include "RC" in the version number.)
>>
>> If the vote passes, the source package becomes a release, and we upload
>> it to our dist dir and tell users about it.
>>
>> In this context, language like this concerns me:
>>
>> "each RC build should come with release notes"
>>
>> These are not release candidates unless we're voting on them, and they
>> certainly must not come with release notes.
>>
>> If an individual is providing nightlies, let's call them nighties, and
>> let's attach "QA notes".
>>
>>
>> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <chip.childers@sungard.com
>> > wrote:
>>
>>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> > Chip,
>>> >
>>> > In the future, we should.  If we were doing this right (which we
>>> aren't today), each RC build should come with release notes about what QA
>>> has found to be problems.  I think what you're putting up right now are
>>> more closer to nightly unstable builds than RC builds.
>>>
>>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>>> packaging the code only.
>>>
>>> We're in a weird state right now, since we won't be able to pass a
>>> vote yet.  The way I see other projects doing this, is that even
>>> unstable builds / source packages can be considered a release.  They
>>> just get labeled something like "alpha" or whatever.  The projects do
>>> vote on them though (which we're not ready for).
>>>
>>> I guess I'll just keep incrementing for now - so that those people
>>> looking at the source package know that it's a new version (vs. Citrix
>>> QA, which I believe is pulling unofficial builds from Jenkins for
>>> functional testing).
>>>
>>> -chip
>>>
>>> > The good news is that the quality has been pretty good so even the
>>> nightly unstable builds are good.  Today, that's mostly due to the majority
>>> features in this release came from Citrix and were already tested by
>>> Citrix.  For future releases, we should follow a process of QA completes
>>> 100% testing and that's a RC build while there's nightly builds for people
>>> who are actually developing if they're interested.
>>> >
>>> > --Alex
>>> >
>>> >> -----Original Message-----
>>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> >> Sent: Monday, September 24, 2012 8:14 PM
>>> >> To: <cl...@incubator.apache.org>
>>> >> Cc: cloudstack-dev@incubator.apache.org
>>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>>> >>
>>> >> Alex,
>>> >>
>>> >> I've been cutting "RC" source code bundles, and have been numbering
>>> them
>>> >> as RCx (Wednesday will be RC3).
>>> >>
>>> >> Do you think I should switch to a more informal scheme until we have
>>> >> something to vote on officially?
>>> >>
>>> >> - chip
>>> >>
>>> >> Sent from my iPhone.
>>> >>
>>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> >>
>>> >> > Hi All,
>>> >> >
>>> >> > I've been reminded that I've neglected to update the community on
>>> the
>>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>>  From now til
>>> >> the actual release, I will give a daily update on the status.  If you
>>> feel anything
>>> >> is missing, please let me know and I'll try to include them on the
>>> next update.
>>> >> >
>>> >> > Summary
>>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>>> (over
>>> >> three weeks ago).  A source code branch has been forked and is called
>>> 4.0.
>>> >> Nightly build is running on Jenkins on the 4.0 build.
>>> >> >
>>> >> > Feature List
>>> >> > There are two features that missed the 4.0 release.  Auto-Scaling
>>> and
>>> >> Brocade Plugin.  Both are due to having significant code changes due
>>> past the
>>> >> code freeze date.
>>> >> >
>>> >> > Code Readiness
>>> >> > - There are ~5 code related reviews on the review board scheduled
>>> for 4.0.
>>> >> Most of them are waiting for review and commit.
>>> >> > - There are <10 bugs on Jira for the first cut of the release.
>>> >> > - Upgrade from previous versions is currently being worked on.
>>>  Scheduled
>>> >> to be done by the end of the week.
>>> >> >
>>> >> > License Readiness
>>> >> > - Majority of the VM configuration issues have been resolved.
>>>  There is one
>>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>>> >> > - Technology export issues are still be worked on by David Nalley
>>> and AFS
>>> >> legal.  This may be a blocking issue.
>>> >> > - Licenses need auditing.
>>> >> >
>>> >> > Doc Readiness
>>> >> > The current plan for docs is to write an INSTALL.TXT to give
>>> instructions on
>>> >> how to install from source.  All docs will be generated to a living
>>> document
>>> >> that continues to improve past the release.  The link to this living
>>> document is
>>> >> to be determined.
>>> >> >
>>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>>  Specifically
>>> >> we need help with Niciria Integration and Caringo documentation.
>>> >> >
>>> >> > QA Status
>>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>>> completion.
>>> >> The number of bugs generated from the tests have been minimum so the
>>> >> quality of the release currently looks pretty good.
>>> >> >
>>> >> > Release Plan
>>> >> > - The current plan is for QA to complete its test cycle between
>>> 9/26-9/28.
>>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>>> >> > - We are currently pushing to clear bugs generated from the test
>>> cycle asap.
>>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>>> submitted for
>>> >> approval to announce.
>>> >> >
>>> >> > --Alex
>>> >> >
>>> >> >
>>> >
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Joe Brockmeier <jz...@zonker.net>]

Hi Ronald, 

(Please don't CC both -dev and -users.) 

On Thu, Nov 1, 2012, at 03:41 AM, ronald higgins wrote:
> Any news on when V4 release is landing? Or did I miss an announcement.

No announcement, per se, but this has been discussed heavily on -dev.
Current status is that the 4.0.0-incubating release is being voted on by
the IPMC. The vote started on Tuesday, and it will end on Friday
(assuming no problems are found that require the vote to be restarted).
Then there's another 24 hours to give mirrors a chance to catch up, etc. 

The "official" release date - assuming all goes well - will be Tuesday
next week. You can see the discussions here:

http://markmail.org/thread/dg6mquboi65t2nho
http://markmail.org/message/ki3nsiqdtlgc76dp

HTH, 

Joe
-- 
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [AFSCS40] Release status for CS 4.0

[ronald higgins <ro...@gmail.com>]

Heh Guys,

Any news on when V4 release is landing? Or did I miss an announcement.

Regards

Ronald

On Tue, Oct 2, 2012 at 10:50 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Cool, thanks Chip.
>
> As a follow up, Apache httpd do "pre-release" versions for testing on the
> dev@ list.
>
> "This directory contains pre-release test versions of the Apache HTTP
> Server and are not officially released tarballs. Please use only for
> testing."
>
> http://httpd.apache.org/dev/dist/
>
> I am not involved with the httpd project, but I am guessing they use this
> as a staging area for builds that people want the community to test, and
> for hosting artefacts that are being voted on. (For a point of reference,
> in CouchDB Land™ we call an RFC on the proposed release to catch any
> concerns before the length release and voting process.)
>
> On Mon, Oct 1, 2012 at 4:29 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <ns...@tumbolia.org> wrote:
>> > Minor correction, "build" is official ASF nomenclature.
>> >
>> > "A Build is a package which is not suitable for distribution to the
>> general
>> > public. They are works-in-progress, and as such the only people builds
>> > should be offered to are other people working on product development at
>> the
>> > foundation."
>> >
>> > "Release candidate" is not, however, and is best avoided. We don't really
>> > do release candidates at apache, so if you use it to talk about voting
>> > artefacts, you risk confusing people who assume you're using the more
>> > common sense of the word. If something is alpha, call it alpha.
>>
>> I like the distinction you made here, specifically that we stop using
>> the term release candidate until we are talking about something that
>> we will / are voting on.  To me, a release "candidate" is exactly
>> that:  a candidate being voted on.
>>
>> Let's start using those terms from now on.  The weekly builds that
>> I've been doing (source only) are just that - builds.
>>
>> -chip
>>
>> > On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org>
>> wrote:
>> >
>> >> Chip,
>> >>
>> >> Can you point me to where you're hosting these builds?
>> >>
>> >> We need to be super careful about the distinction between the following
>> >> items:
>> >>
>> >>    - A build
>> >>       - A source or binary package that will note be voted on
>> >>    - A release candidate
>> >>       - A source package that is being voted on
>> >>    - A release
>> >>       - A source package that has been voted on
>> >>
>> >> (Please note that "build" and "release candidate" are not official ASF
>> >> nomenclature. You could call a build a "package" or a "nightly" or a
>> >> "tarball" or whatever it happens to be. Build kinda works for most
>> things.
>> >> It's a preparation of the source. And release candidate might just be
>> >> called "the voting artefact" or what have you. It's the thing we're
>> voting
>> >> on for a release.)
>> >>
>> >> A binary package will never be anything more than a build that is
>> prepared
>> >> by an individual for the convenience of others. So let's just get that
>> out
>> >> of the way. A binary package can never graduate to anything other than a
>> >> build.
>> >>
>> >> A source package can do many things though.
>> >>
>> >> On the one hand, as an individual, we can prepare source packages as
>> >> snapshots, or nightlies. A committer can upload them to
>> people.apache.org,
>> >> and advertise them to developers. (But we must not advertise them to
>> users
>> >> without heavy caveating.) Generally, these are used by people working on
>> >> the project itself, not with the project. Though, we may want to
>> highlight
>> >> a particular build before starting the official release process, to get
>> >> feedback on things.
>> >>
>> >> If we think we're ready for a release, we can prepare a build to vote
>> on.
>> >> We upload this to people.apache.org, and we start a VOTE thread. At
>> this
>> >> point, the build becomes a release candidate. And only at this point.
>> (Also
>> >> note that because a release candidate must progress to a release without
>> >> any modification, we cannot include "RC" in the version number.)
>> >>
>> >> If the vote passes, the source package becomes a release, and we upload
>> it
>> >> to our dist dir and tell users about it.
>> >>
>> >> In this context, language like this concerns me:
>> >>
>> >> "each RC build should come with release notes"
>> >>
>> >> These are not release candidates unless we're voting on them, and they
>> >> certainly must not come with release notes.
>> >>
>> >> If an individual is providing nightlies, let's call them nighties, and
>> >> let's attach "QA notes".
>> >>
>> >>
>> >> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <
>> chip.childers@sungard.com>wrote:
>> >>
>> >>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>> >>> wrote:
>> >>> > Chip,
>> >>> >
>> >>> > In the future, we should.  If we were doing this right (which we
>> aren't
>> >>> today), each RC build should come with release notes about what QA has
>> >>> found to be problems.  I think what you're putting up right now are
>> more
>> >>> closer to nightly unstable builds than RC builds.
>> >>>
>> >>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>> >>> packaging the code only.
>> >>>
>> >>> We're in a weird state right now, since we won't be able to pass a
>> >>> vote yet.  The way I see other projects doing this, is that even
>> >>> unstable builds / source packages can be considered a release.  They
>> >>> just get labeled something like "alpha" or whatever.  The projects do
>> >>> vote on them though (which we're not ready for).
>> >>>
>> >>> I guess I'll just keep incrementing for now - so that those people
>> >>> looking at the source package know that it's a new version (vs. Citrix
>> >>> QA, which I believe is pulling unofficial builds from Jenkins for
>> >>> functional testing).
>> >>>
>> >>> -chip
>> >>>
>> >>> > The good news is that the quality has been pretty good so even the
>> >>> nightly unstable builds are good.  Today, that's mostly due to the
>> majority
>> >>> features in this release came from Citrix and were already tested by
>> >>> Citrix.  For future releases, we should follow a process of QA
>> completes
>> >>> 100% testing and that's a RC build while there's nightly builds for
>> people
>> >>> who are actually developing if they're interested.
>> >>> >
>> >>> > --Alex
>> >>> >
>> >>> >> -----Original Message-----
>> >>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >>> >> Sent: Monday, September 24, 2012 8:14 PM
>> >>> >> To: <cl...@incubator.apache.org>
>> >>> >> Cc: cloudstack-dev@incubator.apache.org
>> >>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>> >>> >>
>> >>> >> Alex,
>> >>> >>
>> >>> >> I've been cutting "RC" source code bundles, and have been numbering
>> >>> them
>> >>> >> as RCx (Wednesday will be RC3).
>> >>> >>
>> >>> >> Do you think I should switch to a more informal scheme until we have
>> >>> >> something to vote on officially?
>> >>> >>
>> >>> >> - chip
>> >>> >>
>> >>> >> Sent from my iPhone.
>> >>> >>
>> >>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>> >>> wrote:
>> >>> >>
>> >>> >> > Hi All,
>> >>> >> >
>> >>> >> > I've been reminded that I've neglected to update the community on
>> the
>> >>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>> >>>  From now til
>> >>> >> the actual release, I will give a daily update on the status.  If
>> you
>> >>> feel anything
>> >>> >> is missing, please let me know and I'll try to include them on the
>> >>> next update.
>> >>> >> >
>> >>> >> > Summary
>> >>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>> >>> (over
>> >>> >> three weeks ago).  A source code branch has been forked and is
>> called
>> >>> 4.0.
>> >>> >> Nightly build is running on Jenkins on the 4.0 build.
>> >>> >> >
>> >>> >> > Feature List
>> >>> >> > There are two features that missed the 4.0 release.  Auto-Scaling
>> and
>> >>> >> Brocade Plugin.  Both are due to having significant code changes due
>> >>> past the
>> >>> >> code freeze date.
>> >>> >> >
>> >>> >> > Code Readiness
>> >>> >> > - There are ~5 code related reviews on the review board scheduled
>> >>> for 4.0.
>> >>> >> Most of them are waiting for review and commit.
>> >>> >> > - There are <10 bugs on Jira for the first cut of the release.
>> >>> >> > - Upgrade from previous versions is currently being worked on.
>> >>>  Scheduled
>> >>> >> to be done by the end of the week.
>> >>> >> >
>> >>> >> > License Readiness
>> >>> >> > - Majority of the VM configuration issues have been resolved.
>>  There
>> >>> is one
>> >>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> >>> >> > - Technology export issues are still be worked on by David Nalley
>> >>> and AFS
>> >>> >> legal.  This may be a blocking issue.
>> >>> >> > - Licenses need auditing.
>> >>> >> >
>> >>> >> > Doc Readiness
>> >>> >> > The current plan for docs is to write an INSTALL.TXT to give
>> >>> instructions on
>> >>> >> how to install from source.  All docs will be generated to a living
>> >>> document
>> >>> >> that continues to improve past the release.  The link to this living
>> >>> document is
>> >>> >> to be determined.
>> >>> >> >
>> >>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>> >>>  Specifically
>> >>> >> we need help with Niciria Integration and Caringo documentation.
>> >>> >> >
>> >>> >> > QA Status
>> >>> >> > QA is proceeding through the test cycle.  It is currently at 45%
>> of
>> >>> completion.
>> >>> >> The number of bugs generated from the tests have been minimum so the
>> >>> >> quality of the release currently looks pretty good.
>> >>> >> >
>> >>> >> > Release Plan
>> >>> >> > - The current plan is for QA to complete its test cycle between
>> >>> 9/26-9/28.
>> >>> >> > - When QA decides the test cycle is read, we will cut a RC1
>> release.
>> >>> >> > - We are currently pushing to clear bugs generated from the test
>> >>> cycle asap.
>> >>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>> >>> submitted for
>> >>> >> approval to announce.
>> >>> >> >
>> >>> >> > --Alex
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> NS
>> >>
>> >
>> >
>> >
>> > --
>> > NS
>>
>
>
>
> --
> NS

Re: [AFSCS40] Release status for CS 4.0

[ronald higgins <ro...@gmail.com>]

Heh Guys,

Any news on when V4 release is landing? Or did I miss an announcement.

Regards

Ronald

On Tue, Oct 2, 2012 at 10:50 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Cool, thanks Chip.
>
> As a follow up, Apache httpd do "pre-release" versions for testing on the
> dev@ list.
>
> "This directory contains pre-release test versions of the Apache HTTP
> Server and are not officially released tarballs. Please use only for
> testing."
>
> http://httpd.apache.org/dev/dist/
>
> I am not involved with the httpd project, but I am guessing they use this
> as a staging area for builds that people want the community to test, and
> for hosting artefacts that are being voted on. (For a point of reference,
> in CouchDB Land™ we call an RFC on the proposed release to catch any
> concerns before the length release and voting process.)
>
> On Mon, Oct 1, 2012 at 4:29 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <ns...@tumbolia.org> wrote:
>> > Minor correction, "build" is official ASF nomenclature.
>> >
>> > "A Build is a package which is not suitable for distribution to the
>> general
>> > public. They are works-in-progress, and as such the only people builds
>> > should be offered to are other people working on product development at
>> the
>> > foundation."
>> >
>> > "Release candidate" is not, however, and is best avoided. We don't really
>> > do release candidates at apache, so if you use it to talk about voting
>> > artefacts, you risk confusing people who assume you're using the more
>> > common sense of the word. If something is alpha, call it alpha.
>>
>> I like the distinction you made here, specifically that we stop using
>> the term release candidate until we are talking about something that
>> we will / are voting on.  To me, a release "candidate" is exactly
>> that:  a candidate being voted on.
>>
>> Let's start using those terms from now on.  The weekly builds that
>> I've been doing (source only) are just that - builds.
>>
>> -chip
>>
>> > On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org>
>> wrote:
>> >
>> >> Chip,
>> >>
>> >> Can you point me to where you're hosting these builds?
>> >>
>> >> We need to be super careful about the distinction between the following
>> >> items:
>> >>
>> >>    - A build
>> >>       - A source or binary package that will note be voted on
>> >>    - A release candidate
>> >>       - A source package that is being voted on
>> >>    - A release
>> >>       - A source package that has been voted on
>> >>
>> >> (Please note that "build" and "release candidate" are not official ASF
>> >> nomenclature. You could call a build a "package" or a "nightly" or a
>> >> "tarball" or whatever it happens to be. Build kinda works for most
>> things.
>> >> It's a preparation of the source. And release candidate might just be
>> >> called "the voting artefact" or what have you. It's the thing we're
>> voting
>> >> on for a release.)
>> >>
>> >> A binary package will never be anything more than a build that is
>> prepared
>> >> by an individual for the convenience of others. So let's just get that
>> out
>> >> of the way. A binary package can never graduate to anything other than a
>> >> build.
>> >>
>> >> A source package can do many things though.
>> >>
>> >> On the one hand, as an individual, we can prepare source packages as
>> >> snapshots, or nightlies. A committer can upload them to
>> people.apache.org,
>> >> and advertise them to developers. (But we must not advertise them to
>> users
>> >> without heavy caveating.) Generally, these are used by people working on
>> >> the project itself, not with the project. Though, we may want to
>> highlight
>> >> a particular build before starting the official release process, to get
>> >> feedback on things.
>> >>
>> >> If we think we're ready for a release, we can prepare a build to vote
>> on.
>> >> We upload this to people.apache.org, and we start a VOTE thread. At
>> this
>> >> point, the build becomes a release candidate. And only at this point.
>> (Also
>> >> note that because a release candidate must progress to a release without
>> >> any modification, we cannot include "RC" in the version number.)
>> >>
>> >> If the vote passes, the source package becomes a release, and we upload
>> it
>> >> to our dist dir and tell users about it.
>> >>
>> >> In this context, language like this concerns me:
>> >>
>> >> "each RC build should come with release notes"
>> >>
>> >> These are not release candidates unless we're voting on them, and they
>> >> certainly must not come with release notes.
>> >>
>> >> If an individual is providing nightlies, let's call them nighties, and
>> >> let's attach "QA notes".
>> >>
>> >>
>> >> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <
>> chip.childers@sungard.com>wrote:
>> >>
>> >>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>> >>> wrote:
>> >>> > Chip,
>> >>> >
>> >>> > In the future, we should.  If we were doing this right (which we
>> aren't
>> >>> today), each RC build should come with release notes about what QA has
>> >>> found to be problems.  I think what you're putting up right now are
>> more
>> >>> closer to nightly unstable builds than RC builds.
>> >>>
>> >>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>> >>> packaging the code only.
>> >>>
>> >>> We're in a weird state right now, since we won't be able to pass a
>> >>> vote yet.  The way I see other projects doing this, is that even
>> >>> unstable builds / source packages can be considered a release.  They
>> >>> just get labeled something like "alpha" or whatever.  The projects do
>> >>> vote on them though (which we're not ready for).
>> >>>
>> >>> I guess I'll just keep incrementing for now - so that those people
>> >>> looking at the source package know that it's a new version (vs. Citrix
>> >>> QA, which I believe is pulling unofficial builds from Jenkins for
>> >>> functional testing).
>> >>>
>> >>> -chip
>> >>>
>> >>> > The good news is that the quality has been pretty good so even the
>> >>> nightly unstable builds are good.  Today, that's mostly due to the
>> majority
>> >>> features in this release came from Citrix and were already tested by
>> >>> Citrix.  For future releases, we should follow a process of QA
>> completes
>> >>> 100% testing and that's a RC build while there's nightly builds for
>> people
>> >>> who are actually developing if they're interested.
>> >>> >
>> >>> > --Alex
>> >>> >
>> >>> >> -----Original Message-----
>> >>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >>> >> Sent: Monday, September 24, 2012 8:14 PM
>> >>> >> To: <cl...@incubator.apache.org>
>> >>> >> Cc: cloudstack-dev@incubator.apache.org
>> >>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>> >>> >>
>> >>> >> Alex,
>> >>> >>
>> >>> >> I've been cutting "RC" source code bundles, and have been numbering
>> >>> them
>> >>> >> as RCx (Wednesday will be RC3).
>> >>> >>
>> >>> >> Do you think I should switch to a more informal scheme until we have
>> >>> >> something to vote on officially?
>> >>> >>
>> >>> >> - chip
>> >>> >>
>> >>> >> Sent from my iPhone.
>> >>> >>
>> >>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>> >>> wrote:
>> >>> >>
>> >>> >> > Hi All,
>> >>> >> >
>> >>> >> > I've been reminded that I've neglected to update the community on
>> the
>> >>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>> >>>  From now til
>> >>> >> the actual release, I will give a daily update on the status.  If
>> you
>> >>> feel anything
>> >>> >> is missing, please let me know and I'll try to include them on the
>> >>> next update.
>> >>> >> >
>> >>> >> > Summary
>> >>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>> >>> (over
>> >>> >> three weeks ago).  A source code branch has been forked and is
>> called
>> >>> 4.0.
>> >>> >> Nightly build is running on Jenkins on the 4.0 build.
>> >>> >> >
>> >>> >> > Feature List
>> >>> >> > There are two features that missed the 4.0 release.  Auto-Scaling
>> and
>> >>> >> Brocade Plugin.  Both are due to having significant code changes due
>> >>> past the
>> >>> >> code freeze date.
>> >>> >> >
>> >>> >> > Code Readiness
>> >>> >> > - There are ~5 code related reviews on the review board scheduled
>> >>> for 4.0.
>> >>> >> Most of them are waiting for review and commit.
>> >>> >> > - There are <10 bugs on Jira for the first cut of the release.
>> >>> >> > - Upgrade from previous versions is currently being worked on.
>> >>>  Scheduled
>> >>> >> to be done by the end of the week.
>> >>> >> >
>> >>> >> > License Readiness
>> >>> >> > - Majority of the VM configuration issues have been resolved.
>>  There
>> >>> is one
>> >>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> >>> >> > - Technology export issues are still be worked on by David Nalley
>> >>> and AFS
>> >>> >> legal.  This may be a blocking issue.
>> >>> >> > - Licenses need auditing.
>> >>> >> >
>> >>> >> > Doc Readiness
>> >>> >> > The current plan for docs is to write an INSTALL.TXT to give
>> >>> instructions on
>> >>> >> how to install from source.  All docs will be generated to a living
>> >>> document
>> >>> >> that continues to improve past the release.  The link to this living
>> >>> document is
>> >>> >> to be determined.
>> >>> >> >
>> >>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>> >>>  Specifically
>> >>> >> we need help with Niciria Integration and Caringo documentation.
>> >>> >> >
>> >>> >> > QA Status
>> >>> >> > QA is proceeding through the test cycle.  It is currently at 45%
>> of
>> >>> completion.
>> >>> >> The number of bugs generated from the tests have been minimum so the
>> >>> >> quality of the release currently looks pretty good.
>> >>> >> >
>> >>> >> > Release Plan
>> >>> >> > - The current plan is for QA to complete its test cycle between
>> >>> 9/26-9/28.
>> >>> >> > - When QA decides the test cycle is read, we will cut a RC1
>> release.
>> >>> >> > - We are currently pushing to clear bugs generated from the test
>> >>> cycle asap.
>> >>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>> >>> submitted for
>> >>> >> approval to announce.
>> >>> >> >
>> >>> >> > --Alex
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> NS
>> >>
>> >
>> >
>> >
>> > --
>> > NS
>>
>
>
>
> --
> NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

Cool, thanks Chip.

As a follow up, Apache httpd do "pre-release" versions for testing on the
dev@ list.

"This directory contains pre-release test versions of the Apache HTTP
Server and are not officially released tarballs. Please use only for
testing."

http://httpd.apache.org/dev/dist/

I am not involved with the httpd project, but I am guessing they use this
as a staging area for builds that people want the community to test, and
for hosting artefacts that are being voted on. (For a point of reference,
in CouchDB Land™ we call an RFC on the proposed release to catch any
concerns before the length release and voting process.)

On Mon, Oct 1, 2012 at 4:29 PM, Chip Childers <ch...@sungard.com>wrote:

> On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > Minor correction, "build" is official ASF nomenclature.
> >
> > "A Build is a package which is not suitable for distribution to the
> general
> > public. They are works-in-progress, and as such the only people builds
> > should be offered to are other people working on product development at
> the
> > foundation."
> >
> > "Release candidate" is not, however, and is best avoided. We don't really
> > do release candidates at apache, so if you use it to talk about voting
> > artefacts, you risk confusing people who assume you're using the more
> > common sense of the word. If something is alpha, call it alpha.
>
> I like the distinction you made here, specifically that we stop using
> the term release candidate until we are talking about something that
> we will / are voting on.  To me, a release "candidate" is exactly
> that:  a candidate being voted on.
>
> Let's start using those terms from now on.  The weekly builds that
> I've been doing (source only) are just that - builds.
>
> -chip
>
> > On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >
> >> Chip,
> >>
> >> Can you point me to where you're hosting these builds?
> >>
> >> We need to be super careful about the distinction between the following
> >> items:
> >>
> >>    - A build
> >>       - A source or binary package that will note be voted on
> >>    - A release candidate
> >>       - A source package that is being voted on
> >>    - A release
> >>       - A source package that has been voted on
> >>
> >> (Please note that "build" and "release candidate" are not official ASF
> >> nomenclature. You could call a build a "package" or a "nightly" or a
> >> "tarball" or whatever it happens to be. Build kinda works for most
> things.
> >> It's a preparation of the source. And release candidate might just be
> >> called "the voting artefact" or what have you. It's the thing we're
> voting
> >> on for a release.)
> >>
> >> A binary package will never be anything more than a build that is
> prepared
> >> by an individual for the convenience of others. So let's just get that
> out
> >> of the way. A binary package can never graduate to anything other than a
> >> build.
> >>
> >> A source package can do many things though.
> >>
> >> On the one hand, as an individual, we can prepare source packages as
> >> snapshots, or nightlies. A committer can upload them to
> people.apache.org,
> >> and advertise them to developers. (But we must not advertise them to
> users
> >> without heavy caveating.) Generally, these are used by people working on
> >> the project itself, not with the project. Though, we may want to
> highlight
> >> a particular build before starting the official release process, to get
> >> feedback on things.
> >>
> >> If we think we're ready for a release, we can prepare a build to vote
> on.
> >> We upload this to people.apache.org, and we start a VOTE thread. At
> this
> >> point, the build becomes a release candidate. And only at this point.
> (Also
> >> note that because a release candidate must progress to a release without
> >> any modification, we cannot include "RC" in the version number.)
> >>
> >> If the vote passes, the source package becomes a release, and we upload
> it
> >> to our dist dir and tell users about it.
> >>
> >> In this context, language like this concerns me:
> >>
> >> "each RC build should come with release notes"
> >>
> >> These are not release candidates unless we're voting on them, and they
> >> certainly must not come with release notes.
> >>
> >> If an individual is providing nightlies, let's call them nighties, and
> >> let's attach "QA notes".
> >>
> >>
> >> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <
> chip.childers@sungard.com>wrote:
> >>
> >>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
> >>> wrote:
> >>> > Chip,
> >>> >
> >>> > In the future, we should.  If we were doing this right (which we
> aren't
> >>> today), each RC build should come with release notes about what QA has
> >>> found to be problems.  I think what you're putting up right now are
> more
> >>> closer to nightly unstable builds than RC builds.
> >>>
> >>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
> >>> packaging the code only.
> >>>
> >>> We're in a weird state right now, since we won't be able to pass a
> >>> vote yet.  The way I see other projects doing this, is that even
> >>> unstable builds / source packages can be considered a release.  They
> >>> just get labeled something like "alpha" or whatever.  The projects do
> >>> vote on them though (which we're not ready for).
> >>>
> >>> I guess I'll just keep incrementing for now - so that those people
> >>> looking at the source package know that it's a new version (vs. Citrix
> >>> QA, which I believe is pulling unofficial builds from Jenkins for
> >>> functional testing).
> >>>
> >>> -chip
> >>>
> >>> > The good news is that the quality has been pretty good so even the
> >>> nightly unstable builds are good.  Today, that's mostly due to the
> majority
> >>> features in this release came from Citrix and were already tested by
> >>> Citrix.  For future releases, we should follow a process of QA
> completes
> >>> 100% testing and that's a RC build while there's nightly builds for
> people
> >>> who are actually developing if they're interested.
> >>> >
> >>> > --Alex
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
> >>> >> Sent: Monday, September 24, 2012 8:14 PM
> >>> >> To: <cl...@incubator.apache.org>
> >>> >> Cc: cloudstack-dev@incubator.apache.org
> >>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
> >>> >>
> >>> >> Alex,
> >>> >>
> >>> >> I've been cutting "RC" source code bundles, and have been numbering
> >>> them
> >>> >> as RCx (Wednesday will be RC3).
> >>> >>
> >>> >> Do you think I should switch to a more informal scheme until we have
> >>> >> something to vote on officially?
> >>> >>
> >>> >> - chip
> >>> >>
> >>> >> Sent from my iPhone.
> >>> >>
> >>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
> >>> wrote:
> >>> >>
> >>> >> > Hi All,
> >>> >> >
> >>> >> > I've been reminded that I've neglected to update the community on
> the
> >>> >> current status for CloudStack 4.0.  I apologize for that oversight.
> >>>  From now til
> >>> >> the actual release, I will give a daily update on the status.  If
> you
> >>> feel anything
> >>> >> is missing, please let me know and I'll try to include them on the
> >>> next update.
> >>> >> >
> >>> >> > Summary
> >>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> >>> (over
> >>> >> three weeks ago).  A source code branch has been forked and is
> called
> >>> 4.0.
> >>> >> Nightly build is running on Jenkins on the 4.0 build.
> >>> >> >
> >>> >> > Feature List
> >>> >> > There are two features that missed the 4.0 release.  Auto-Scaling
> and
> >>> >> Brocade Plugin.  Both are due to having significant code changes due
> >>> past the
> >>> >> code freeze date.
> >>> >> >
> >>> >> > Code Readiness
> >>> >> > - There are ~5 code related reviews on the review board scheduled
> >>> for 4.0.
> >>> >> Most of them are waiting for review and commit.
> >>> >> > - There are <10 bugs on Jira for the first cut of the release.
> >>> >> > - Upgrade from previous versions is currently being worked on.
> >>>  Scheduled
> >>> >> to be done by the end of the week.
> >>> >> >
> >>> >> > License Readiness
> >>> >> > - Majority of the VM configuration issues have been resolved.
>  There
> >>> is one
> >>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> >>> >> > - Technology export issues are still be worked on by David Nalley
> >>> and AFS
> >>> >> legal.  This may be a blocking issue.
> >>> >> > - Licenses need auditing.
> >>> >> >
> >>> >> > Doc Readiness
> >>> >> > The current plan for docs is to write an INSTALL.TXT to give
> >>> instructions on
> >>> >> how to install from source.  All docs will be generated to a living
> >>> document
> >>> >> that continues to improve past the release.  The link to this living
> >>> document is
> >>> >> to be determined.
> >>> >> >
> >>> >> > TODO:  Docs need help on the new features in the 4.0 release.
> >>>  Specifically
> >>> >> we need help with Niciria Integration and Caringo documentation.
> >>> >> >
> >>> >> > QA Status
> >>> >> > QA is proceeding through the test cycle.  It is currently at 45%
> of
> >>> completion.
> >>> >> The number of bugs generated from the tests have been minimum so the
> >>> >> quality of the release currently looks pretty good.
> >>> >> >
> >>> >> > Release Plan
> >>> >> > - The current plan is for QA to complete its test cycle between
> >>> 9/26-9/28.
> >>> >> > - When QA decides the test cycle is read, we will cut a RC1
> release.
> >>> >> > - We are currently pushing to clear bugs generated from the test
> >>> cycle asap.
> >>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
> >>> submitted for
> >>> >> approval to announce.
> >>> >> >
> >>> >> > --Alex
> >>> >> >
> >>> >> >
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> NS
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

Cool, thanks Chip.

As a follow up, Apache httpd do "pre-release" versions for testing on the
dev@ list.

"This directory contains pre-release test versions of the Apache HTTP
Server and are not officially released tarballs. Please use only for
testing."

http://httpd.apache.org/dev/dist/

I am not involved with the httpd project, but I am guessing they use this
as a staging area for builds that people want the community to test, and
for hosting artefacts that are being voted on. (For a point of reference,
in CouchDB Land™ we call an RFC on the proposed release to catch any
concerns before the length release and voting process.)

On Mon, Oct 1, 2012 at 4:29 PM, Chip Childers <ch...@sungard.com>wrote:

> On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > Minor correction, "build" is official ASF nomenclature.
> >
> > "A Build is a package which is not suitable for distribution to the
> general
> > public. They are works-in-progress, and as such the only people builds
> > should be offered to are other people working on product development at
> the
> > foundation."
> >
> > "Release candidate" is not, however, and is best avoided. We don't really
> > do release candidates at apache, so if you use it to talk about voting
> > artefacts, you risk confusing people who assume you're using the more
> > common sense of the word. If something is alpha, call it alpha.
>
> I like the distinction you made here, specifically that we stop using
> the term release candidate until we are talking about something that
> we will / are voting on.  To me, a release "candidate" is exactly
> that:  a candidate being voted on.
>
> Let's start using those terms from now on.  The weekly builds that
> I've been doing (source only) are just that - builds.
>
> -chip
>
> > On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >
> >> Chip,
> >>
> >> Can you point me to where you're hosting these builds?
> >>
> >> We need to be super careful about the distinction between the following
> >> items:
> >>
> >>    - A build
> >>       - A source or binary package that will note be voted on
> >>    - A release candidate
> >>       - A source package that is being voted on
> >>    - A release
> >>       - A source package that has been voted on
> >>
> >> (Please note that "build" and "release candidate" are not official ASF
> >> nomenclature. You could call a build a "package" or a "nightly" or a
> >> "tarball" or whatever it happens to be. Build kinda works for most
> things.
> >> It's a preparation of the source. And release candidate might just be
> >> called "the voting artefact" or what have you. It's the thing we're
> voting
> >> on for a release.)
> >>
> >> A binary package will never be anything more than a build that is
> prepared
> >> by an individual for the convenience of others. So let's just get that
> out
> >> of the way. A binary package can never graduate to anything other than a
> >> build.
> >>
> >> A source package can do many things though.
> >>
> >> On the one hand, as an individual, we can prepare source packages as
> >> snapshots, or nightlies. A committer can upload them to
> people.apache.org,
> >> and advertise them to developers. (But we must not advertise them to
> users
> >> without heavy caveating.) Generally, these are used by people working on
> >> the project itself, not with the project. Though, we may want to
> highlight
> >> a particular build before starting the official release process, to get
> >> feedback on things.
> >>
> >> If we think we're ready for a release, we can prepare a build to vote
> on.
> >> We upload this to people.apache.org, and we start a VOTE thread. At
> this
> >> point, the build becomes a release candidate. And only at this point.
> (Also
> >> note that because a release candidate must progress to a release without
> >> any modification, we cannot include "RC" in the version number.)
> >>
> >> If the vote passes, the source package becomes a release, and we upload
> it
> >> to our dist dir and tell users about it.
> >>
> >> In this context, language like this concerns me:
> >>
> >> "each RC build should come with release notes"
> >>
> >> These are not release candidates unless we're voting on them, and they
> >> certainly must not come with release notes.
> >>
> >> If an individual is providing nightlies, let's call them nighties, and
> >> let's attach "QA notes".
> >>
> >>
> >> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <
> chip.childers@sungard.com>wrote:
> >>
> >>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
> >>> wrote:
> >>> > Chip,
> >>> >
> >>> > In the future, we should.  If we were doing this right (which we
> aren't
> >>> today), each RC build should come with release notes about what QA has
> >>> found to be problems.  I think what you're putting up right now are
> more
> >>> closer to nightly unstable builds than RC builds.
> >>>
> >>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
> >>> packaging the code only.
> >>>
> >>> We're in a weird state right now, since we won't be able to pass a
> >>> vote yet.  The way I see other projects doing this, is that even
> >>> unstable builds / source packages can be considered a release.  They
> >>> just get labeled something like "alpha" or whatever.  The projects do
> >>> vote on them though (which we're not ready for).
> >>>
> >>> I guess I'll just keep incrementing for now - so that those people
> >>> looking at the source package know that it's a new version (vs. Citrix
> >>> QA, which I believe is pulling unofficial builds from Jenkins for
> >>> functional testing).
> >>>
> >>> -chip
> >>>
> >>> > The good news is that the quality has been pretty good so even the
> >>> nightly unstable builds are good.  Today, that's mostly due to the
> majority
> >>> features in this release came from Citrix and were already tested by
> >>> Citrix.  For future releases, we should follow a process of QA
> completes
> >>> 100% testing and that's a RC build while there's nightly builds for
> people
> >>> who are actually developing if they're interested.
> >>> >
> >>> > --Alex
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
> >>> >> Sent: Monday, September 24, 2012 8:14 PM
> >>> >> To: <cl...@incubator.apache.org>
> >>> >> Cc: cloudstack-dev@incubator.apache.org
> >>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
> >>> >>
> >>> >> Alex,
> >>> >>
> >>> >> I've been cutting "RC" source code bundles, and have been numbering
> >>> them
> >>> >> as RCx (Wednesday will be RC3).
> >>> >>
> >>> >> Do you think I should switch to a more informal scheme until we have
> >>> >> something to vote on officially?
> >>> >>
> >>> >> - chip
> >>> >>
> >>> >> Sent from my iPhone.
> >>> >>
> >>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
> >>> wrote:
> >>> >>
> >>> >> > Hi All,
> >>> >> >
> >>> >> > I've been reminded that I've neglected to update the community on
> the
> >>> >> current status for CloudStack 4.0.  I apologize for that oversight.
> >>>  From now til
> >>> >> the actual release, I will give a daily update on the status.  If
> you
> >>> feel anything
> >>> >> is missing, please let me know and I'll try to include them on the
> >>> next update.
> >>> >> >
> >>> >> > Summary
> >>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> >>> (over
> >>> >> three weeks ago).  A source code branch has been forked and is
> called
> >>> 4.0.
> >>> >> Nightly build is running on Jenkins on the 4.0 build.
> >>> >> >
> >>> >> > Feature List
> >>> >> > There are two features that missed the 4.0 release.  Auto-Scaling
> and
> >>> >> Brocade Plugin.  Both are due to having significant code changes due
> >>> past the
> >>> >> code freeze date.
> >>> >> >
> >>> >> > Code Readiness
> >>> >> > - There are ~5 code related reviews on the review board scheduled
> >>> for 4.0.
> >>> >> Most of them are waiting for review and commit.
> >>> >> > - There are <10 bugs on Jira for the first cut of the release.
> >>> >> > - Upgrade from previous versions is currently being worked on.
> >>>  Scheduled
> >>> >> to be done by the end of the week.
> >>> >> >
> >>> >> > License Readiness
> >>> >> > - Majority of the VM configuration issues have been resolved.
>  There
> >>> is one
> >>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> >>> >> > - Technology export issues are still be worked on by David Nalley
> >>> and AFS
> >>> >> legal.  This may be a blocking issue.
> >>> >> > - Licenses need auditing.
> >>> >> >
> >>> >> > Doc Readiness
> >>> >> > The current plan for docs is to write an INSTALL.TXT to give
> >>> instructions on
> >>> >> how to install from source.  All docs will be generated to a living
> >>> document
> >>> >> that continues to improve past the release.  The link to this living
> >>> document is
> >>> >> to be determined.
> >>> >> >
> >>> >> > TODO:  Docs need help on the new features in the 4.0 release.
> >>>  Specifically
> >>> >> we need help with Niciria Integration and Caringo documentation.
> >>> >> >
> >>> >> > QA Status
> >>> >> > QA is proceeding through the test cycle.  It is currently at 45%
> of
> >>> completion.
> >>> >> The number of bugs generated from the tests have been minimum so the
> >>> >> quality of the release currently looks pretty good.
> >>> >> >
> >>> >> > Release Plan
> >>> >> > - The current plan is for QA to complete its test cycle between
> >>> 9/26-9/28.
> >>> >> > - When QA decides the test cycle is read, we will cut a RC1
> release.
> >>> >> > - We are currently pushing to clear bugs generated from the test
> >>> cycle asap.
> >>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
> >>> submitted for
> >>> >> approval to announce.
> >>> >> >
> >>> >> > --Alex
> >>> >> >
> >>> >> >
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> NS
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Minor correction, "build" is official ASF nomenclature.
>
> "A Build is a package which is not suitable for distribution to the general
> public. They are works-in-progress, and as such the only people builds
> should be offered to are other people working on product development at the
> foundation."
>
> "Release candidate" is not, however, and is best avoided. We don't really
> do release candidates at apache, so if you use it to talk about voting
> artefacts, you risk confusing people who assume you're using the more
> common sense of the word. If something is alpha, call it alpha.

I like the distinction you made here, specifically that we stop using
the term release candidate until we are talking about something that
we will / are voting on.  To me, a release "candidate" is exactly
that:  a candidate being voted on.

Let's start using those terms from now on.  The weekly builds that
I've been doing (source only) are just that - builds.

-chip

> On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org> wrote:
>
>> Chip,
>>
>> Can you point me to where you're hosting these builds?
>>
>> We need to be super careful about the distinction between the following
>> items:
>>
>>    - A build
>>       - A source or binary package that will note be voted on
>>    - A release candidate
>>       - A source package that is being voted on
>>    - A release
>>       - A source package that has been voted on
>>
>> (Please note that "build" and "release candidate" are not official ASF
>> nomenclature. You could call a build a "package" or a "nightly" or a
>> "tarball" or whatever it happens to be. Build kinda works for most things.
>> It's a preparation of the source. And release candidate might just be
>> called "the voting artefact" or what have you. It's the thing we're voting
>> on for a release.)
>>
>> A binary package will never be anything more than a build that is prepared
>> by an individual for the convenience of others. So let's just get that out
>> of the way. A binary package can never graduate to anything other than a
>> build.
>>
>> A source package can do many things though.
>>
>> On the one hand, as an individual, we can prepare source packages as
>> snapshots, or nightlies. A committer can upload them to people.apache.org,
>> and advertise them to developers. (But we must not advertise them to users
>> without heavy caveating.) Generally, these are used by people working on
>> the project itself, not with the project. Though, we may want to highlight
>> a particular build before starting the official release process, to get
>> feedback on things.
>>
>> If we think we're ready for a release, we can prepare a build to vote on.
>> We upload this to people.apache.org, and we start a VOTE thread. At this
>> point, the build becomes a release candidate. And only at this point. (Also
>> note that because a release candidate must progress to a release without
>> any modification, we cannot include "RC" in the version number.)
>>
>> If the vote passes, the source package becomes a release, and we upload it
>> to our dist dir and tell users about it.
>>
>> In this context, language like this concerns me:
>>
>> "each RC build should come with release notes"
>>
>> These are not release candidates unless we're voting on them, and they
>> certainly must not come with release notes.
>>
>> If an individual is providing nightlies, let's call them nighties, and
>> let's attach "QA notes".
>>
>>
>> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:
>>
>>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> > Chip,
>>> >
>>> > In the future, we should.  If we were doing this right (which we aren't
>>> today), each RC build should come with release notes about what QA has
>>> found to be problems.  I think what you're putting up right now are more
>>> closer to nightly unstable builds than RC builds.
>>>
>>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>>> packaging the code only.
>>>
>>> We're in a weird state right now, since we won't be able to pass a
>>> vote yet.  The way I see other projects doing this, is that even
>>> unstable builds / source packages can be considered a release.  They
>>> just get labeled something like "alpha" or whatever.  The projects do
>>> vote on them though (which we're not ready for).
>>>
>>> I guess I'll just keep incrementing for now - so that those people
>>> looking at the source package know that it's a new version (vs. Citrix
>>> QA, which I believe is pulling unofficial builds from Jenkins for
>>> functional testing).
>>>
>>> -chip
>>>
>>> > The good news is that the quality has been pretty good so even the
>>> nightly unstable builds are good.  Today, that's mostly due to the majority
>>> features in this release came from Citrix and were already tested by
>>> Citrix.  For future releases, we should follow a process of QA completes
>>> 100% testing and that's a RC build while there's nightly builds for people
>>> who are actually developing if they're interested.
>>> >
>>> > --Alex
>>> >
>>> >> -----Original Message-----
>>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> >> Sent: Monday, September 24, 2012 8:14 PM
>>> >> To: <cl...@incubator.apache.org>
>>> >> Cc: cloudstack-dev@incubator.apache.org
>>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>>> >>
>>> >> Alex,
>>> >>
>>> >> I've been cutting "RC" source code bundles, and have been numbering
>>> them
>>> >> as RCx (Wednesday will be RC3).
>>> >>
>>> >> Do you think I should switch to a more informal scheme until we have
>>> >> something to vote on officially?
>>> >>
>>> >> - chip
>>> >>
>>> >> Sent from my iPhone.
>>> >>
>>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> >>
>>> >> > Hi All,
>>> >> >
>>> >> > I've been reminded that I've neglected to update the community on the
>>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>>  From now til
>>> >> the actual release, I will give a daily update on the status.  If you
>>> feel anything
>>> >> is missing, please let me know and I'll try to include them on the
>>> next update.
>>> >> >
>>> >> > Summary
>>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>>> (over
>>> >> three weeks ago).  A source code branch has been forked and is called
>>> 4.0.
>>> >> Nightly build is running on Jenkins on the 4.0 build.
>>> >> >
>>> >> > Feature List
>>> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
>>> >> Brocade Plugin.  Both are due to having significant code changes due
>>> past the
>>> >> code freeze date.
>>> >> >
>>> >> > Code Readiness
>>> >> > - There are ~5 code related reviews on the review board scheduled
>>> for 4.0.
>>> >> Most of them are waiting for review and commit.
>>> >> > - There are <10 bugs on Jira for the first cut of the release.
>>> >> > - Upgrade from previous versions is currently being worked on.
>>>  Scheduled
>>> >> to be done by the end of the week.
>>> >> >
>>> >> > License Readiness
>>> >> > - Majority of the VM configuration issues have been resolved.  There
>>> is one
>>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>>> >> > - Technology export issues are still be worked on by David Nalley
>>> and AFS
>>> >> legal.  This may be a blocking issue.
>>> >> > - Licenses need auditing.
>>> >> >
>>> >> > Doc Readiness
>>> >> > The current plan for docs is to write an INSTALL.TXT to give
>>> instructions on
>>> >> how to install from source.  All docs will be generated to a living
>>> document
>>> >> that continues to improve past the release.  The link to this living
>>> document is
>>> >> to be determined.
>>> >> >
>>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>>  Specifically
>>> >> we need help with Niciria Integration and Caringo documentation.
>>> >> >
>>> >> > QA Status
>>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>>> completion.
>>> >> The number of bugs generated from the tests have been minimum so the
>>> >> quality of the release currently looks pretty good.
>>> >> >
>>> >> > Release Plan
>>> >> > - The current plan is for QA to complete its test cycle between
>>> 9/26-9/28.
>>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>>> >> > - We are currently pushing to clear bugs generated from the test
>>> cycle asap.
>>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>>> submitted for
>>> >> approval to announce.
>>> >> >
>>> >> > --Alex
>>> >> >
>>> >> >
>>> >
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Minor correction, "build" is official ASF nomenclature.
>
> "A Build is a package which is not suitable for distribution to the general
> public. They are works-in-progress, and as such the only people builds
> should be offered to are other people working on product development at the
> foundation."
>
> "Release candidate" is not, however, and is best avoided. We don't really
> do release candidates at apache, so if you use it to talk about voting
> artefacts, you risk confusing people who assume you're using the more
> common sense of the word. If something is alpha, call it alpha.

I like the distinction you made here, specifically that we stop using
the term release candidate until we are talking about something that
we will / are voting on.  To me, a release "candidate" is exactly
that:  a candidate being voted on.

Let's start using those terms from now on.  The weekly builds that
I've been doing (source only) are just that - builds.

-chip

> On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org> wrote:
>
>> Chip,
>>
>> Can you point me to where you're hosting these builds?
>>
>> We need to be super careful about the distinction between the following
>> items:
>>
>>    - A build
>>       - A source or binary package that will note be voted on
>>    - A release candidate
>>       - A source package that is being voted on
>>    - A release
>>       - A source package that has been voted on
>>
>> (Please note that "build" and "release candidate" are not official ASF
>> nomenclature. You could call a build a "package" or a "nightly" or a
>> "tarball" or whatever it happens to be. Build kinda works for most things.
>> It's a preparation of the source. And release candidate might just be
>> called "the voting artefact" or what have you. It's the thing we're voting
>> on for a release.)
>>
>> A binary package will never be anything more than a build that is prepared
>> by an individual for the convenience of others. So let's just get that out
>> of the way. A binary package can never graduate to anything other than a
>> build.
>>
>> A source package can do many things though.
>>
>> On the one hand, as an individual, we can prepare source packages as
>> snapshots, or nightlies. A committer can upload them to people.apache.org,
>> and advertise them to developers. (But we must not advertise them to users
>> without heavy caveating.) Generally, these are used by people working on
>> the project itself, not with the project. Though, we may want to highlight
>> a particular build before starting the official release process, to get
>> feedback on things.
>>
>> If we think we're ready for a release, we can prepare a build to vote on.
>> We upload this to people.apache.org, and we start a VOTE thread. At this
>> point, the build becomes a release candidate. And only at this point. (Also
>> note that because a release candidate must progress to a release without
>> any modification, we cannot include "RC" in the version number.)
>>
>> If the vote passes, the source package becomes a release, and we upload it
>> to our dist dir and tell users about it.
>>
>> In this context, language like this concerns me:
>>
>> "each RC build should come with release notes"
>>
>> These are not release candidates unless we're voting on them, and they
>> certainly must not come with release notes.
>>
>> If an individual is providing nightlies, let's call them nighties, and
>> let's attach "QA notes".
>>
>>
>> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:
>>
>>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> > Chip,
>>> >
>>> > In the future, we should.  If we were doing this right (which we aren't
>>> today), each RC build should come with release notes about what QA has
>>> found to be problems.  I think what you're putting up right now are more
>>> closer to nightly unstable builds than RC builds.
>>>
>>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>>> packaging the code only.
>>>
>>> We're in a weird state right now, since we won't be able to pass a
>>> vote yet.  The way I see other projects doing this, is that even
>>> unstable builds / source packages can be considered a release.  They
>>> just get labeled something like "alpha" or whatever.  The projects do
>>> vote on them though (which we're not ready for).
>>>
>>> I guess I'll just keep incrementing for now - so that those people
>>> looking at the source package know that it's a new version (vs. Citrix
>>> QA, which I believe is pulling unofficial builds from Jenkins for
>>> functional testing).
>>>
>>> -chip
>>>
>>> > The good news is that the quality has been pretty good so even the
>>> nightly unstable builds are good.  Today, that's mostly due to the majority
>>> features in this release came from Citrix and were already tested by
>>> Citrix.  For future releases, we should follow a process of QA completes
>>> 100% testing and that's a RC build while there's nightly builds for people
>>> who are actually developing if they're interested.
>>> >
>>> > --Alex
>>> >
>>> >> -----Original Message-----
>>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> >> Sent: Monday, September 24, 2012 8:14 PM
>>> >> To: <cl...@incubator.apache.org>
>>> >> Cc: cloudstack-dev@incubator.apache.org
>>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>>> >>
>>> >> Alex,
>>> >>
>>> >> I've been cutting "RC" source code bundles, and have been numbering
>>> them
>>> >> as RCx (Wednesday will be RC3).
>>> >>
>>> >> Do you think I should switch to a more informal scheme until we have
>>> >> something to vote on officially?
>>> >>
>>> >> - chip
>>> >>
>>> >> Sent from my iPhone.
>>> >>
>>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>> >>
>>> >> > Hi All,
>>> >> >
>>> >> > I've been reminded that I've neglected to update the community on the
>>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>>  From now til
>>> >> the actual release, I will give a daily update on the status.  If you
>>> feel anything
>>> >> is missing, please let me know and I'll try to include them on the
>>> next update.
>>> >> >
>>> >> > Summary
>>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>>> (over
>>> >> three weeks ago).  A source code branch has been forked and is called
>>> 4.0.
>>> >> Nightly build is running on Jenkins on the 4.0 build.
>>> >> >
>>> >> > Feature List
>>> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
>>> >> Brocade Plugin.  Both are due to having significant code changes due
>>> past the
>>> >> code freeze date.
>>> >> >
>>> >> > Code Readiness
>>> >> > - There are ~5 code related reviews on the review board scheduled
>>> for 4.0.
>>> >> Most of them are waiting for review and commit.
>>> >> > - There are <10 bugs on Jira for the first cut of the release.
>>> >> > - Upgrade from previous versions is currently being worked on.
>>>  Scheduled
>>> >> to be done by the end of the week.
>>> >> >
>>> >> > License Readiness
>>> >> > - Majority of the VM configuration issues have been resolved.  There
>>> is one
>>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>>> >> > - Technology export issues are still be worked on by David Nalley
>>> and AFS
>>> >> legal.  This may be a blocking issue.
>>> >> > - Licenses need auditing.
>>> >> >
>>> >> > Doc Readiness
>>> >> > The current plan for docs is to write an INSTALL.TXT to give
>>> instructions on
>>> >> how to install from source.  All docs will be generated to a living
>>> document
>>> >> that continues to improve past the release.  The link to this living
>>> document is
>>> >> to be determined.
>>> >> >
>>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>>  Specifically
>>> >> we need help with Niciria Integration and Caringo documentation.
>>> >> >
>>> >> > QA Status
>>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>>> completion.
>>> >> The number of bugs generated from the tests have been minimum so the
>>> >> quality of the release currently looks pretty good.
>>> >> >
>>> >> > Release Plan
>>> >> > - The current plan is for QA to complete its test cycle between
>>> 9/26-9/28.
>>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>>> >> > - We are currently pushing to clear bugs generated from the test
>>> cycle asap.
>>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>>> submitted for
>>> >> approval to announce.
>>> >> >
>>> >> > --Alex
>>> >> >
>>> >> >
>>> >
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

Minor correction, "build" is official ASF nomenclature.

"A Build is a package which is not suitable for distribution to the general
public. They are works-in-progress, and as such the only people builds
should be offered to are other people working on product development at the
foundation."

"Release candidate" is not, however, and is best avoided. We don't really
do release candidates at apache, so if you use it to talk about voting
artefacts, you risk confusing people who assume you're using the more
common sense of the word. If something is alpha, call it alpha.

On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Chip,
>
> Can you point me to where you're hosting these builds?
>
> We need to be super careful about the distinction between the following
> items:
>
>    - A build
>       - A source or binary package that will note be voted on
>    - A release candidate
>       - A source package that is being voted on
>    - A release
>       - A source package that has been voted on
>
> (Please note that "build" and "release candidate" are not official ASF
> nomenclature. You could call a build a "package" or a "nightly" or a
> "tarball" or whatever it happens to be. Build kinda works for most things.
> It's a preparation of the source. And release candidate might just be
> called "the voting artefact" or what have you. It's the thing we're voting
> on for a release.)
>
> A binary package will never be anything more than a build that is prepared
> by an individual for the convenience of others. So let's just get that out
> of the way. A binary package can never graduate to anything other than a
> build.
>
> A source package can do many things though.
>
> On the one hand, as an individual, we can prepare source packages as
> snapshots, or nightlies. A committer can upload them to people.apache.org,
> and advertise them to developers. (But we must not advertise them to users
> without heavy caveating.) Generally, these are used by people working on
> the project itself, not with the project. Though, we may want to highlight
> a particular build before starting the official release process, to get
> feedback on things.
>
> If we think we're ready for a release, we can prepare a build to vote on.
> We upload this to people.apache.org, and we start a VOTE thread. At this
> point, the build becomes a release candidate. And only at this point. (Also
> note that because a release candidate must progress to a release without
> any modification, we cannot include "RC" in the version number.)
>
> If the vote passes, the source package becomes a release, and we upload it
> to our dist dir and tell users about it.
>
> In this context, language like this concerns me:
>
> "each RC build should come with release notes"
>
> These are not release candidates unless we're voting on them, and they
> certainly must not come with release notes.
>
> If an individual is providing nightlies, let's call them nighties, and
> let's attach "QA notes".
>
>
> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>> wrote:
>> > Chip,
>> >
>> > In the future, we should.  If we were doing this right (which we aren't
>> today), each RC build should come with release notes about what QA has
>> found to be problems.  I think what you're putting up right now are more
>> closer to nightly unstable builds than RC builds.
>>
>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>> packaging the code only.
>>
>> We're in a weird state right now, since we won't be able to pass a
>> vote yet.  The way I see other projects doing this, is that even
>> unstable builds / source packages can be considered a release.  They
>> just get labeled something like "alpha" or whatever.  The projects do
>> vote on them though (which we're not ready for).
>>
>> I guess I'll just keep incrementing for now - so that those people
>> looking at the source package know that it's a new version (vs. Citrix
>> QA, which I believe is pulling unofficial builds from Jenkins for
>> functional testing).
>>
>> -chip
>>
>> > The good news is that the quality has been pretty good so even the
>> nightly unstable builds are good.  Today, that's mostly due to the majority
>> features in this release came from Citrix and were already tested by
>> Citrix.  For future releases, we should follow a process of QA completes
>> 100% testing and that's a RC build while there's nightly builds for people
>> who are actually developing if they're interested.
>> >
>> > --Alex
>> >
>> >> -----Original Message-----
>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >> Sent: Monday, September 24, 2012 8:14 PM
>> >> To: <cl...@incubator.apache.org>
>> >> Cc: cloudstack-dev@incubator.apache.org
>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>> >>
>> >> Alex,
>> >>
>> >> I've been cutting "RC" source code bundles, and have been numbering
>> them
>> >> as RCx (Wednesday will be RC3).
>> >>
>> >> Do you think I should switch to a more informal scheme until we have
>> >> something to vote on officially?
>> >>
>> >> - chip
>> >>
>> >> Sent from my iPhone.
>> >>
>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>> wrote:
>> >>
>> >> > Hi All,
>> >> >
>> >> > I've been reminded that I've neglected to update the community on the
>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>  From now til
>> >> the actual release, I will give a daily update on the status.  If you
>> feel anything
>> >> is missing, please let me know and I'll try to include them on the
>> next update.
>> >> >
>> >> > Summary
>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>> (over
>> >> three weeks ago).  A source code branch has been forked and is called
>> 4.0.
>> >> Nightly build is running on Jenkins on the 4.0 build.
>> >> >
>> >> > Feature List
>> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
>> >> Brocade Plugin.  Both are due to having significant code changes due
>> past the
>> >> code freeze date.
>> >> >
>> >> > Code Readiness
>> >> > - There are ~5 code related reviews on the review board scheduled
>> for 4.0.
>> >> Most of them are waiting for review and commit.
>> >> > - There are <10 bugs on Jira for the first cut of the release.
>> >> > - Upgrade from previous versions is currently being worked on.
>>  Scheduled
>> >> to be done by the end of the week.
>> >> >
>> >> > License Readiness
>> >> > - Majority of the VM configuration issues have been resolved.  There
>> is one
>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> >> > - Technology export issues are still be worked on by David Nalley
>> and AFS
>> >> legal.  This may be a blocking issue.
>> >> > - Licenses need auditing.
>> >> >
>> >> > Doc Readiness
>> >> > The current plan for docs is to write an INSTALL.TXT to give
>> instructions on
>> >> how to install from source.  All docs will be generated to a living
>> document
>> >> that continues to improve past the release.  The link to this living
>> document is
>> >> to be determined.
>> >> >
>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>  Specifically
>> >> we need help with Niciria Integration and Caringo documentation.
>> >> >
>> >> > QA Status
>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>> completion.
>> >> The number of bugs generated from the tests have been minimum so the
>> >> quality of the release currently looks pretty good.
>> >> >
>> >> > Release Plan
>> >> > - The current plan is for QA to complete its test cycle between
>> 9/26-9/28.
>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>> >> > - We are currently pushing to clear bugs generated from the test
>> cycle asap.
>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>> submitted for
>> >> approval to announce.
>> >> >
>> >> > --Alex
>> >> >
>> >> >
>> >
>>
>
>
>
> --
> NS
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

Minor correction, "build" is official ASF nomenclature.

"A Build is a package which is not suitable for distribution to the general
public. They are works-in-progress, and as such the only people builds
should be offered to are other people working on product development at the
foundation."

"Release candidate" is not, however, and is best avoided. We don't really
do release candidates at apache, so if you use it to talk about voting
artefacts, you risk confusing people who assume you're using the more
common sense of the word. If something is alpha, call it alpha.

On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Chip,
>
> Can you point me to where you're hosting these builds?
>
> We need to be super careful about the distinction between the following
> items:
>
>    - A build
>       - A source or binary package that will note be voted on
>    - A release candidate
>       - A source package that is being voted on
>    - A release
>       - A source package that has been voted on
>
> (Please note that "build" and "release candidate" are not official ASF
> nomenclature. You could call a build a "package" or a "nightly" or a
> "tarball" or whatever it happens to be. Build kinda works for most things.
> It's a preparation of the source. And release candidate might just be
> called "the voting artefact" or what have you. It's the thing we're voting
> on for a release.)
>
> A binary package will never be anything more than a build that is prepared
> by an individual for the convenience of others. So let's just get that out
> of the way. A binary package can never graduate to anything other than a
> build.
>
> A source package can do many things though.
>
> On the one hand, as an individual, we can prepare source packages as
> snapshots, or nightlies. A committer can upload them to people.apache.org,
> and advertise them to developers. (But we must not advertise them to users
> without heavy caveating.) Generally, these are used by people working on
> the project itself, not with the project. Though, we may want to highlight
> a particular build before starting the official release process, to get
> feedback on things.
>
> If we think we're ready for a release, we can prepare a build to vote on.
> We upload this to people.apache.org, and we start a VOTE thread. At this
> point, the build becomes a release candidate. And only at this point. (Also
> note that because a release candidate must progress to a release without
> any modification, we cannot include "RC" in the version number.)
>
> If the vote passes, the source package becomes a release, and we upload it
> to our dist dir and tell users about it.
>
> In this context, language like this concerns me:
>
> "each RC build should come with release notes"
>
> These are not release candidates unless we're voting on them, and they
> certainly must not come with release notes.
>
> If an individual is providing nightlies, let's call them nighties, and
> let's attach "QA notes".
>
>
> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com>
>> wrote:
>> > Chip,
>> >
>> > In the future, we should.  If we were doing this right (which we aren't
>> today), each RC build should come with release notes about what QA has
>> found to be problems.  I think what you're putting up right now are more
>> closer to nightly unstable builds than RC builds.
>>
>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>> packaging the code only.
>>
>> We're in a weird state right now, since we won't be able to pass a
>> vote yet.  The way I see other projects doing this, is that even
>> unstable builds / source packages can be considered a release.  They
>> just get labeled something like "alpha" or whatever.  The projects do
>> vote on them though (which we're not ready for).
>>
>> I guess I'll just keep incrementing for now - so that those people
>> looking at the source package know that it's a new version (vs. Citrix
>> QA, which I believe is pulling unofficial builds from Jenkins for
>> functional testing).
>>
>> -chip
>>
>> > The good news is that the quality has been pretty good so even the
>> nightly unstable builds are good.  Today, that's mostly due to the majority
>> features in this release came from Citrix and were already tested by
>> Citrix.  For future releases, we should follow a process of QA completes
>> 100% testing and that's a RC build while there's nightly builds for people
>> who are actually developing if they're interested.
>> >
>> > --Alex
>> >
>> >> -----Original Message-----
>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >> Sent: Monday, September 24, 2012 8:14 PM
>> >> To: <cl...@incubator.apache.org>
>> >> Cc: cloudstack-dev@incubator.apache.org
>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>> >>
>> >> Alex,
>> >>
>> >> I've been cutting "RC" source code bundles, and have been numbering
>> them
>> >> as RCx (Wednesday will be RC3).
>> >>
>> >> Do you think I should switch to a more informal scheme until we have
>> >> something to vote on officially?
>> >>
>> >> - chip
>> >>
>> >> Sent from my iPhone.
>> >>
>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com>
>> wrote:
>> >>
>> >> > Hi All,
>> >> >
>> >> > I've been reminded that I've neglected to update the community on the
>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>  From now til
>> >> the actual release, I will give a daily update on the status.  If you
>> feel anything
>> >> is missing, please let me know and I'll try to include them on the
>> next update.
>> >> >
>> >> > Summary
>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>> (over
>> >> three weeks ago).  A source code branch has been forked and is called
>> 4.0.
>> >> Nightly build is running on Jenkins on the 4.0 build.
>> >> >
>> >> > Feature List
>> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
>> >> Brocade Plugin.  Both are due to having significant code changes due
>> past the
>> >> code freeze date.
>> >> >
>> >> > Code Readiness
>> >> > - There are ~5 code related reviews on the review board scheduled
>> for 4.0.
>> >> Most of them are waiting for review and commit.
>> >> > - There are <10 bugs on Jira for the first cut of the release.
>> >> > - Upgrade from previous versions is currently being worked on.
>>  Scheduled
>> >> to be done by the end of the week.
>> >> >
>> >> > License Readiness
>> >> > - Majority of the VM configuration issues have been resolved.  There
>> is one
>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> >> > - Technology export issues are still be worked on by David Nalley
>> and AFS
>> >> legal.  This may be a blocking issue.
>> >> > - Licenses need auditing.
>> >> >
>> >> > Doc Readiness
>> >> > The current plan for docs is to write an INSTALL.TXT to give
>> instructions on
>> >> how to install from source.  All docs will be generated to a living
>> document
>> >> that continues to improve past the release.  The link to this living
>> document is
>> >> to be determined.
>> >> >
>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>  Specifically
>> >> we need help with Niciria Integration and Caringo documentation.
>> >> >
>> >> > QA Status
>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>> completion.
>> >> The number of bugs generated from the tests have been minimum so the
>> >> quality of the release currently looks pretty good.
>> >> >
>> >> > Release Plan
>> >> > - The current plan is for QA to complete its test cycle between
>> 9/26-9/28.
>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>> >> > - We are currently pushing to clear bugs generated from the test
>> cycle asap.
>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be
>> submitted for
>> >> approval to announce.
>> >> >
>> >> > --Alex
>> >> >
>> >> >
>> >
>>
>
>
>
> --
> NS
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

On Sun, Sep 30, 2012 at 7:23 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Chip,
>
> Can you point me to where you're hosting these builds?

p.a.o/~chipchilders/cloudstack/4.0 - exactly where they are supposed to go. ;-)

> We need to be super careful about the distinction between the following
> items:
>
>    - A build
>       - A source or binary package that will note be voted on
>    - A release candidate
>       - A source package that is being voted on
>    - A release
>       - A source package that has been voted on

Good reminder.

> (Please note that "build" and "release candidate" are not official ASF
> nomenclature. You could call a build a "package" or a "nightly" or a
> "tarball" or whatever it happens to be. Build kinda works for most things.
> It's a preparation of the source. And release candidate might just be
> called "the voting artefact" or what have you. It's the thing we're voting
> on for a release.)
>
> A binary package will never be anything more than a build that is prepared
> by an individual for the convenience of others. So let's just get that out
> of the way. A binary package can never graduate to anything other than a
> build.
>
> A source package can do many things though.
>
> On the one hand, as an individual, we can prepare source packages as
> snapshots, or nightlies. A committer can upload them to people.apache.org,
> and advertise them to developers. (But we must not advertise them to users
> without heavy caveating.) Generally, these are used by people working on
> the project itself, not with the project. Though, we may want to highlight
> a particular build before starting the official release process, to get
> feedback on things.
>
> If we think we're ready for a release, we can prepare a build to vote on.
> We upload this to people.apache.org, and we start a VOTE thread. At this
> point, the build becomes a release candidate. And only at this point. (Also
> note that because a release candidate must progress to a release without
> any modification, we cannot include "RC" in the version number.)

Agreed on the RC not being part of an actual release candidate's
version number, due to the nature of the voting / distribution
process.

> If the vote passes, the source package becomes a release, and we upload it
> to our dist dir and tell users about it.
>
> In this context, language like this concerns me:
>
> "each RC build should come with release notes"
>
> These are not release candidates unless we're voting on them, and they
> certainly must not come with release notes.
>
> If an individual is providing nightlies, let's call them nighties, and
> let's attach "QA notes".

+1 to calling them something besides release notes

>
> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com> wrote:
>> > Chip,
>> >
>> > In the future, we should.  If we were doing this right (which we aren't
>> today), each RC build should come with release notes about what QA has
>> found to be problems.  I think what you're putting up right now are more
>> closer to nightly unstable builds than RC builds.
>>
>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>> packaging the code only.
>>
>> We're in a weird state right now, since we won't be able to pass a
>> vote yet.  The way I see other projects doing this, is that even
>> unstable builds / source packages can be considered a release.  They
>> just get labeled something like "alpha" or whatever.  The projects do
>> vote on them though (which we're not ready for).
>>
>> I guess I'll just keep incrementing for now - so that those people
>> looking at the source package know that it's a new version (vs. Citrix
>> QA, which I believe is pulling unofficial builds from Jenkins for
>> functional testing).
>>
>> -chip
>>
>> > The good news is that the quality has been pretty good so even the
>> nightly unstable builds are good.  Today, that's mostly due to the majority
>> features in this release came from Citrix and were already tested by
>> Citrix.  For future releases, we should follow a process of QA completes
>> 100% testing and that's a RC build while there's nightly builds for people
>> who are actually developing if they're interested.
>> >
>> > --Alex
>> >
>> >> -----Original Message-----
>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >> Sent: Monday, September 24, 2012 8:14 PM
>> >> To: <cl...@incubator.apache.org>
>> >> Cc: cloudstack-dev@incubator.apache.org
>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>> >>
>> >> Alex,
>> >>
>> >> I've been cutting "RC" source code bundles, and have been numbering them
>> >> as RCx (Wednesday will be RC3).
>> >>
>> >> Do you think I should switch to a more informal scheme until we have
>> >> something to vote on officially?
>> >>
>> >> - chip
>> >>
>> >> Sent from my iPhone.
>> >>
>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
>> >>
>> >> > Hi All,
>> >> >
>> >> > I've been reminded that I've neglected to update the community on the
>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>>  From now til
>> >> the actual release, I will give a daily update on the status.  If you
>> feel anything
>> >> is missing, please let me know and I'll try to include them on the next
>> update.
>> >> >
>> >> > Summary
>> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
>> (over
>> >> three weeks ago).  A source code branch has been forked and is called
>> 4.0.
>> >> Nightly build is running on Jenkins on the 4.0 build.
>> >> >
>> >> > Feature List
>> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
>> >> Brocade Plugin.  Both are due to having significant code changes due
>> past the
>> >> code freeze date.
>> >> >
>> >> > Code Readiness
>> >> > - There are ~5 code related reviews on the review board scheduled for
>> 4.0.
>> >> Most of them are waiting for review and commit.
>> >> > - There are <10 bugs on Jira for the first cut of the release.
>> >> > - Upgrade from previous versions is currently being worked on.
>>  Scheduled
>> >> to be done by the end of the week.
>> >> >
>> >> > License Readiness
>> >> > - Majority of the VM configuration issues have been resolved.  There
>> is one
>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> >> > - Technology export issues are still be worked on by David Nalley and
>> AFS
>> >> legal.  This may be a blocking issue.
>> >> > - Licenses need auditing.
>> >> >
>> >> > Doc Readiness
>> >> > The current plan for docs is to write an INSTALL.TXT to give
>> instructions on
>> >> how to install from source.  All docs will be generated to a living
>> document
>> >> that continues to improve past the release.  The link to this living
>> document is
>> >> to be determined.
>> >> >
>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>>  Specifically
>> >> we need help with Niciria Integration and Caringo documentation.
>> >> >
>> >> > QA Status
>> >> > QA is proceeding through the test cycle.  It is currently at 45% of
>> completion.
>> >> The number of bugs generated from the tests have been minimum so the
>> >> quality of the release currently looks pretty good.
>> >> >
>> >> > Release Plan
>> >> > - The current plan is for QA to complete its test cycle between
>> 9/26-9/28.
>> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
>> >> > - We are currently pushing to clear bugs generated from the test
>> cycle asap.
>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
>> for
>> >> approval to announce.
>> >> >
>> >> > --Alex
>> >> >
>> >> >
>> >
>>
>
>
>
> --
> NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

Chip,

Can you point me to where you're hosting these builds?

We need to be super careful about the distinction between the following
items:

   - A build
      - A source or binary package that will note be voted on
   - A release candidate
      - A source package that is being voted on
   - A release
      - A source package that has been voted on

(Please note that "build" and "release candidate" are not official ASF
nomenclature. You could call a build a "package" or a "nightly" or a
"tarball" or whatever it happens to be. Build kinda works for most things.
It's a preparation of the source. And release candidate might just be
called "the voting artefact" or what have you. It's the thing we're voting
on for a release.)

A binary package will never be anything more than a build that is prepared
by an individual for the convenience of others. So let's just get that out
of the way. A binary package can never graduate to anything other than a
build.

A source package can do many things though.

On the one hand, as an individual, we can prepare source packages as
snapshots, or nightlies. A committer can upload them to people.apache.org,
and advertise them to developers. (But we must not advertise them to users
without heavy caveating.) Generally, these are used by people working on
the project itself, not with the project. Though, we may want to highlight
a particular build before starting the official release process, to get
feedback on things.

If we think we're ready for a release, we can prepare a build to vote on.
We upload this to people.apache.org, and we start a VOTE thread. At this
point, the build becomes a release candidate. And only at this point. (Also
note that because a release candidate must progress to a release without
any modification, we cannot include "RC" in the version number.)

If the vote passes, the source package becomes a release, and we upload it
to our dist dir and tell users about it.

In this context, language like this concerns me:

"each RC build should come with release notes"

These are not release candidates unless we're voting on them, and they
certainly must not come with release notes.

If an individual is providing nightlies, let's call them nighties, and
let's attach "QA notes".


On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:

> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com> wrote:
> > Chip,
> >
> > In the future, we should.  If we were doing this right (which we aren't
> today), each RC build should come with release notes about what QA has
> found to be problems.  I think what you're putting up right now are more
> closer to nightly unstable builds than RC builds.
>
> Agreed on that front.  Really though, I'm not doing a "build".  I'm
> packaging the code only.
>
> We're in a weird state right now, since we won't be able to pass a
> vote yet.  The way I see other projects doing this, is that even
> unstable builds / source packages can be considered a release.  They
> just get labeled something like "alpha" or whatever.  The projects do
> vote on them though (which we're not ready for).
>
> I guess I'll just keep incrementing for now - so that those people
> looking at the source package know that it's a new version (vs. Citrix
> QA, which I believe is pulling unofficial builds from Jenkins for
> functional testing).
>
> -chip
>
> > The good news is that the quality has been pretty good so even the
> nightly unstable builds are good.  Today, that's mostly due to the majority
> features in this release came from Citrix and were already tested by
> Citrix.  For future releases, we should follow a process of QA completes
> 100% testing and that's a RC build while there's nightly builds for people
> who are actually developing if they're interested.
> >
> > --Alex
> >
> >> -----Original Message-----
> >> From: Chip Childers [mailto:chip.childers@sungard.com]
> >> Sent: Monday, September 24, 2012 8:14 PM
> >> To: <cl...@incubator.apache.org>
> >> Cc: cloudstack-dev@incubator.apache.org
> >> Subject: Re: [AFSCS40] Release status for CS 4.0
> >>
> >> Alex,
> >>
> >> I've been cutting "RC" source code bundles, and have been numbering them
> >> as RCx (Wednesday will be RC3).
> >>
> >> Do you think I should switch to a more informal scheme until we have
> >> something to vote on officially?
> >>
> >> - chip
> >>
> >> Sent from my iPhone.
> >>
> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
> >>
> >> > Hi All,
> >> >
> >> > I've been reminded that I've neglected to update the community on the
> >> current status for CloudStack 4.0.  I apologize for that oversight.
>  From now til
> >> the actual release, I will give a daily update on the status.  If you
> feel anything
> >> is missing, please let me know and I'll try to include them on the next
> update.
> >> >
> >> > Summary
> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> (over
> >> three weeks ago).  A source code branch has been forked and is called
> 4.0.
> >> Nightly build is running on Jenkins on the 4.0 build.
> >> >
> >> > Feature List
> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
> >> Brocade Plugin.  Both are due to having significant code changes due
> past the
> >> code freeze date.
> >> >
> >> > Code Readiness
> >> > - There are ~5 code related reviews on the review board scheduled for
> 4.0.
> >> Most of them are waiting for review and commit.
> >> > - There are <10 bugs on Jira for the first cut of the release.
> >> > - Upgrade from previous versions is currently being worked on.
>  Scheduled
> >> to be done by the end of the week.
> >> >
> >> > License Readiness
> >> > - Majority of the VM configuration issues have been resolved.  There
> is one
> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> >> > - Technology export issues are still be worked on by David Nalley and
> AFS
> >> legal.  This may be a blocking issue.
> >> > - Licenses need auditing.
> >> >
> >> > Doc Readiness
> >> > The current plan for docs is to write an INSTALL.TXT to give
> instructions on
> >> how to install from source.  All docs will be generated to a living
> document
> >> that continues to improve past the release.  The link to this living
> document is
> >> to be determined.
> >> >
> >> > TODO:  Docs need help on the new features in the 4.0 release.
>  Specifically
> >> we need help with Niciria Integration and Caringo documentation.
> >> >
> >> > QA Status
> >> > QA is proceeding through the test cycle.  It is currently at 45% of
> completion.
> >> The number of bugs generated from the tests have been minimum so the
> >> quality of the release currently looks pretty good.
> >> >
> >> > Release Plan
> >> > - The current plan is for QA to complete its test cycle between
> 9/26-9/28.
> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
> >> > - We are currently pushing to clear bugs generated from the test
> cycle asap.
> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
> for
> >> approval to announce.
> >> >
> >> > --Alex
> >> >
> >> >
> >
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Noah Slater <ns...@tumbolia.org>]

Chip,

Can you point me to where you're hosting these builds?

We need to be super careful about the distinction between the following
items:

   - A build
      - A source or binary package that will note be voted on
   - A release candidate
      - A source package that is being voted on
   - A release
      - A source package that has been voted on

(Please note that "build" and "release candidate" are not official ASF
nomenclature. You could call a build a "package" or a "nightly" or a
"tarball" or whatever it happens to be. Build kinda works for most things.
It's a preparation of the source. And release candidate might just be
called "the voting artefact" or what have you. It's the thing we're voting
on for a release.)

A binary package will never be anything more than a build that is prepared
by an individual for the convenience of others. So let's just get that out
of the way. A binary package can never graduate to anything other than a
build.

A source package can do many things though.

On the one hand, as an individual, we can prepare source packages as
snapshots, or nightlies. A committer can upload them to people.apache.org,
and advertise them to developers. (But we must not advertise them to users
without heavy caveating.) Generally, these are used by people working on
the project itself, not with the project. Though, we may want to highlight
a particular build before starting the official release process, to get
feedback on things.

If we think we're ready for a release, we can prepare a build to vote on.
We upload this to people.apache.org, and we start a VOTE thread. At this
point, the build becomes a release candidate. And only at this point. (Also
note that because a release candidate must progress to a release without
any modification, we cannot include "RC" in the version number.)

If the vote passes, the source package becomes a release, and we upload it
to our dist dir and tell users about it.

In this context, language like this concerns me:

"each RC build should come with release notes"

These are not release candidates unless we're voting on them, and they
certainly must not come with release notes.

If an individual is providing nightlies, let's call them nighties, and
let's attach "QA notes".


On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:

> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com> wrote:
> > Chip,
> >
> > In the future, we should.  If we were doing this right (which we aren't
> today), each RC build should come with release notes about what QA has
> found to be problems.  I think what you're putting up right now are more
> closer to nightly unstable builds than RC builds.
>
> Agreed on that front.  Really though, I'm not doing a "build".  I'm
> packaging the code only.
>
> We're in a weird state right now, since we won't be able to pass a
> vote yet.  The way I see other projects doing this, is that even
> unstable builds / source packages can be considered a release.  They
> just get labeled something like "alpha" or whatever.  The projects do
> vote on them though (which we're not ready for).
>
> I guess I'll just keep incrementing for now - so that those people
> looking at the source package know that it's a new version (vs. Citrix
> QA, which I believe is pulling unofficial builds from Jenkins for
> functional testing).
>
> -chip
>
> > The good news is that the quality has been pretty good so even the
> nightly unstable builds are good.  Today, that's mostly due to the majority
> features in this release came from Citrix and were already tested by
> Citrix.  For future releases, we should follow a process of QA completes
> 100% testing and that's a RC build while there's nightly builds for people
> who are actually developing if they're interested.
> >
> > --Alex
> >
> >> -----Original Message-----
> >> From: Chip Childers [mailto:chip.childers@sungard.com]
> >> Sent: Monday, September 24, 2012 8:14 PM
> >> To: <cl...@incubator.apache.org>
> >> Cc: cloudstack-dev@incubator.apache.org
> >> Subject: Re: [AFSCS40] Release status for CS 4.0
> >>
> >> Alex,
> >>
> >> I've been cutting "RC" source code bundles, and have been numbering them
> >> as RCx (Wednesday will be RC3).
> >>
> >> Do you think I should switch to a more informal scheme until we have
> >> something to vote on officially?
> >>
> >> - chip
> >>
> >> Sent from my iPhone.
> >>
> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
> >>
> >> > Hi All,
> >> >
> >> > I've been reminded that I've neglected to update the community on the
> >> current status for CloudStack 4.0.  I apologize for that oversight.
>  From now til
> >> the actual release, I will give a daily update on the status.  If you
> feel anything
> >> is missing, please let me know and I'll try to include them on the next
> update.
> >> >
> >> > Summary
> >> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage
> (over
> >> three weeks ago).  A source code branch has been forked and is called
> 4.0.
> >> Nightly build is running on Jenkins on the 4.0 build.
> >> >
> >> > Feature List
> >> > There are two features that missed the 4.0 release.  Auto-Scaling and
> >> Brocade Plugin.  Both are due to having significant code changes due
> past the
> >> code freeze date.
> >> >
> >> > Code Readiness
> >> > - There are ~5 code related reviews on the review board scheduled for
> 4.0.
> >> Most of them are waiting for review and commit.
> >> > - There are <10 bugs on Jira for the first cut of the release.
> >> > - Upgrade from previous versions is currently being worked on.
>  Scheduled
> >> to be done by the end of the week.
> >> >
> >> > License Readiness
> >> > - Majority of the VM configuration issues have been resolved.  There
> is one
> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> >> > - Technology export issues are still be worked on by David Nalley and
> AFS
> >> legal.  This may be a blocking issue.
> >> > - Licenses need auditing.
> >> >
> >> > Doc Readiness
> >> > The current plan for docs is to write an INSTALL.TXT to give
> instructions on
> >> how to install from source.  All docs will be generated to a living
> document
> >> that continues to improve past the release.  The link to this living
> document is
> >> to be determined.
> >> >
> >> > TODO:  Docs need help on the new features in the 4.0 release.
>  Specifically
> >> we need help with Niciria Integration and Caringo documentation.
> >> >
> >> > QA Status
> >> > QA is proceeding through the test cycle.  It is currently at 45% of
> completion.
> >> The number of bugs generated from the tests have been minimum so the
> >> quality of the release currently looks pretty good.
> >> >
> >> > Release Plan
> >> > - The current plan is for QA to complete its test cycle between
> 9/26-9/28.
> >> > - When QA decides the test cycle is read, we will cut a RC1 release.
> >> > - We are currently pushing to clear bugs generated from the test
> cycle asap.
> >> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted
> for
> >> approval to announce.
> >> >
> >> > --Alex
> >> >
> >> >
> >
>



-- 
NS

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com> wrote:
> Chip,
>
> In the future, we should.  If we were doing this right (which we aren't today), each RC build should come with release notes about what QA has found to be problems.  I think what you're putting up right now are more closer to nightly unstable builds than RC builds.

Agreed on that front.  Really though, I'm not doing a "build".  I'm
packaging the code only.

We're in a weird state right now, since we won't be able to pass a
vote yet.  The way I see other projects doing this, is that even
unstable builds / source packages can be considered a release.  They
just get labeled something like "alpha" or whatever.  The projects do
vote on them though (which we're not ready for).

I guess I'll just keep incrementing for now - so that those people
looking at the source package know that it's a new version (vs. Citrix
QA, which I believe is pulling unofficial builds from Jenkins for
functional testing).

-chip

> The good news is that the quality has been pretty good so even the nightly unstable builds are good.  Today, that's mostly due to the majority features in this release came from Citrix and were already tested by Citrix.  For future releases, we should follow a process of QA completes 100% testing and that's a RC build while there's nightly builds for people who are actually developing if they're interested.
>
> --Alex
>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Monday, September 24, 2012 8:14 PM
>> To: <cl...@incubator.apache.org>
>> Cc: cloudstack-dev@incubator.apache.org
>> Subject: Re: [AFSCS40] Release status for CS 4.0
>>
>> Alex,
>>
>> I've been cutting "RC" source code bundles, and have been numbering them
>> as RCx (Wednesday will be RC3).
>>
>> Do you think I should switch to a more informal scheme until we have
>> something to vote on officially?
>>
>> - chip
>>
>> Sent from my iPhone.
>>
>> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
>>
>> > Hi All,
>> >
>> > I've been reminded that I've neglected to update the community on the
>> current status for CloudStack 4.0.  I apologize for that oversight.  From now til
>> the actual release, I will give a daily update on the status.  If you feel anything
>> is missing, please let me know and I'll try to include them on the next update.
>> >
>> > Summary
>> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage (over
>> three weeks ago).  A source code branch has been forked and is called 4.0.
>> Nightly build is running on Jenkins on the 4.0 build.
>> >
>> > Feature List
>> > There are two features that missed the 4.0 release.  Auto-Scaling and
>> Brocade Plugin.  Both are due to having significant code changes due past the
>> code freeze date.
>> >
>> > Code Readiness
>> > - There are ~5 code related reviews on the review board scheduled for 4.0.
>> Most of them are waiting for review and commit.
>> > - There are <10 bugs on Jira for the first cut of the release.
>> > - Upgrade from previous versions is currently being worked on.  Scheduled
>> to be done by the end of the week.
>> >
>> > License Readiness
>> > - Majority of the VM configuration issues have been resolved.  There is one
>> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> > - Technology export issues are still be worked on by David Nalley and AFS
>> legal.  This may be a blocking issue.
>> > - Licenses need auditing.
>> >
>> > Doc Readiness
>> > The current plan for docs is to write an INSTALL.TXT to give instructions on
>> how to install from source.  All docs will be generated to a living document
>> that continues to improve past the release.  The link to this living document is
>> to be determined.
>> >
>> > TODO:  Docs need help on the new features in the 4.0 release.  Specifically
>> we need help with Niciria Integration and Caringo documentation.
>> >
>> > QA Status
>> > QA is proceeding through the test cycle.  It is currently at 45% of completion.
>> The number of bugs generated from the tests have been minimum so the
>> quality of the release currently looks pretty good.
>> >
>> > Release Plan
>> > - The current plan is for QA to complete its test cycle between 9/26-9/28.
>> > - When QA decides the test cycle is read, we will cut a RC1 release.
>> > - We are currently pushing to clear bugs generated from the test cycle asap.
>> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted for
>> approval to announce.
>> >
>> > --Alex
>> >
>> >
>

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@citrix.com> wrote:
> Chip,
>
> In the future, we should.  If we were doing this right (which we aren't today), each RC build should come with release notes about what QA has found to be problems.  I think what you're putting up right now are more closer to nightly unstable builds than RC builds.

Agreed on that front.  Really though, I'm not doing a "build".  I'm
packaging the code only.

We're in a weird state right now, since we won't be able to pass a
vote yet.  The way I see other projects doing this, is that even
unstable builds / source packages can be considered a release.  They
just get labeled something like "alpha" or whatever.  The projects do
vote on them though (which we're not ready for).

I guess I'll just keep incrementing for now - so that those people
looking at the source package know that it's a new version (vs. Citrix
QA, which I believe is pulling unofficial builds from Jenkins for
functional testing).

-chip

> The good news is that the quality has been pretty good so even the nightly unstable builds are good.  Today, that's mostly due to the majority features in this release came from Citrix and were already tested by Citrix.  For future releases, we should follow a process of QA completes 100% testing and that's a RC build while there's nightly builds for people who are actually developing if they're interested.
>
> --Alex
>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Monday, September 24, 2012 8:14 PM
>> To: <cl...@incubator.apache.org>
>> Cc: cloudstack-dev@incubator.apache.org
>> Subject: Re: [AFSCS40] Release status for CS 4.0
>>
>> Alex,
>>
>> I've been cutting "RC" source code bundles, and have been numbering them
>> as RCx (Wednesday will be RC3).
>>
>> Do you think I should switch to a more informal scheme until we have
>> something to vote on officially?
>>
>> - chip
>>
>> Sent from my iPhone.
>>
>> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
>>
>> > Hi All,
>> >
>> > I've been reminded that I've neglected to update the community on the
>> current status for CloudStack 4.0.  I apologize for that oversight.  From now til
>> the actual release, I will give a daily update on the status.  If you feel anything
>> is missing, please let me know and I'll try to include them on the next update.
>> >
>> > Summary
>> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage (over
>> three weeks ago).  A source code branch has been forked and is called 4.0.
>> Nightly build is running on Jenkins on the 4.0 build.
>> >
>> > Feature List
>> > There are two features that missed the 4.0 release.  Auto-Scaling and
>> Brocade Plugin.  Both are due to having significant code changes due past the
>> code freeze date.
>> >
>> > Code Readiness
>> > - There are ~5 code related reviews on the review board scheduled for 4.0.
>> Most of them are waiting for review and commit.
>> > - There are <10 bugs on Jira for the first cut of the release.
>> > - Upgrade from previous versions is currently being worked on.  Scheduled
>> to be done by the end of the week.
>> >
>> > License Readiness
>> > - Majority of the VM configuration issues have been resolved.  There is one
>> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> > - Technology export issues are still be worked on by David Nalley and AFS
>> legal.  This may be a blocking issue.
>> > - Licenses need auditing.
>> >
>> > Doc Readiness
>> > The current plan for docs is to write an INSTALL.TXT to give instructions on
>> how to install from source.  All docs will be generated to a living document
>> that continues to improve past the release.  The link to this living document is
>> to be determined.
>> >
>> > TODO:  Docs need help on the new features in the 4.0 release.  Specifically
>> we need help with Niciria Integration and Caringo documentation.
>> >
>> > QA Status
>> > QA is proceeding through the test cycle.  It is currently at 45% of completion.
>> The number of bugs generated from the tests have been minimum so the
>> quality of the release currently looks pretty good.
>> >
>> > Release Plan
>> > - The current plan is for QA to complete its test cycle between 9/26-9/28.
>> > - When QA decides the test cycle is read, we will cut a RC1 release.
>> > - We are currently pushing to clear bugs generated from the test cycle asap.
>> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted for
>> approval to announce.
>> >
>> > --Alex
>> >
>> >
>

RE: [AFSCS40] Release status for CS 4.0

[Alex Huang <Al...@citrix.com>]

Chip,

In the future, we should.  If we were doing this right (which we aren't today), each RC build should come with release notes about what QA has found to be problems.  I think what you're putting up right now are more closer to nightly unstable builds than RC builds.  

The good news is that the quality has been pretty good so even the nightly unstable builds are good.  Today, that's mostly due to the majority features in this release came from Citrix and were already tested by Citrix.  For future releases, we should follow a process of QA completes 100% testing and that's a RC build while there's nightly builds for people who are actually developing if they're interested.

--Alex

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, September 24, 2012 8:14 PM
> To: <cl...@incubator.apache.org>
> Cc: cloudstack-dev@incubator.apache.org
> Subject: Re: [AFSCS40] Release status for CS 4.0
> 
> Alex,
> 
> I've been cutting "RC" source code bundles, and have been numbering them
> as RCx (Wednesday will be RC3).
> 
> Do you think I should switch to a more informal scheme until we have
> something to vote on officially?
> 
> - chip
> 
> Sent from my iPhone.
> 
> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
> 
> > Hi All,
> >
> > I've been reminded that I've neglected to update the community on the
> current status for CloudStack 4.0.  I apologize for that oversight.  From now til
> the actual release, I will give a daily update on the status.  If you feel anything
> is missing, please let me know and I'll try to include them on the next update.
> >
> > Summary
> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage (over
> three weeks ago).  A source code branch has been forked and is called 4.0.
> Nightly build is running on Jenkins on the 4.0 build.
> >
> > Feature List
> > There are two features that missed the 4.0 release.  Auto-Scaling and
> Brocade Plugin.  Both are due to having significant code changes due past the
> code freeze date.
> >
> > Code Readiness
> > - There are ~5 code related reviews on the review board scheduled for 4.0.
> Most of them are waiting for review and commit.
> > - There are <10 bugs on Jira for the first cut of the release.
> > - Upgrade from previous versions is currently being worked on.  Scheduled
> to be done by the end of the week.
> >
> > License Readiness
> > - Majority of the VM configuration issues have been resolved.  There is one
> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > - Technology export issues are still be worked on by David Nalley and AFS
> legal.  This may be a blocking issue.
> > - Licenses need auditing.
> >
> > Doc Readiness
> > The current plan for docs is to write an INSTALL.TXT to give instructions on
> how to install from source.  All docs will be generated to a living document
> that continues to improve past the release.  The link to this living document is
> to be determined.
> >
> > TODO:  Docs need help on the new features in the 4.0 release.  Specifically
> we need help with Niciria Integration and Caringo documentation.
> >
> > QA Status
> > QA is proceeding through the test cycle.  It is currently at 45% of completion.
> The number of bugs generated from the tests have been minimum so the
> quality of the release currently looks pretty good.
> >
> > Release Plan
> > - The current plan is for QA to complete its test cycle between 9/26-9/28.
> > - When QA decides the test cycle is read, we will cut a RC1 release.
> > - We are currently pushing to clear bugs generated from the test cycle asap.
> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted for
> approval to announce.
> >
> > --Alex
> >
> >

RE: [AFSCS40] Release status for CS 4.0

[Alex Huang <Al...@citrix.com>]

Chip,

In the future, we should.  If we were doing this right (which we aren't today), each RC build should come with release notes about what QA has found to be problems.  I think what you're putting up right now are more closer to nightly unstable builds than RC builds.  

The good news is that the quality has been pretty good so even the nightly unstable builds are good.  Today, that's mostly due to the majority features in this release came from Citrix and were already tested by Citrix.  For future releases, we should follow a process of QA completes 100% testing and that's a RC build while there's nightly builds for people who are actually developing if they're interested.

--Alex

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, September 24, 2012 8:14 PM
> To: <cl...@incubator.apache.org>
> Cc: cloudstack-dev@incubator.apache.org
> Subject: Re: [AFSCS40] Release status for CS 4.0
> 
> Alex,
> 
> I've been cutting "RC" source code bundles, and have been numbering them
> as RCx (Wednesday will be RC3).
> 
> Do you think I should switch to a more informal scheme until we have
> something to vote on officially?
> 
> - chip
> 
> Sent from my iPhone.
> 
> On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:
> 
> > Hi All,
> >
> > I've been reminded that I've neglected to update the community on the
> current status for CloudStack 4.0.  I apologize for that oversight.  From now til
> the actual release, I will give a daily update on the status.  If you feel anything
> is missing, please let me know and I'll try to include them on the next update.
> >
> > Summary
> > As of 9/24/2012, CloudStack 4.0 release has past code freeze stage (over
> three weeks ago).  A source code branch has been forked and is called 4.0.
> Nightly build is running on Jenkins on the 4.0 build.
> >
> > Feature List
> > There are two features that missed the 4.0 release.  Auto-Scaling and
> Brocade Plugin.  Both are due to having significant code changes due past the
> code freeze date.
> >
> > Code Readiness
> > - There are ~5 code related reviews on the review board scheduled for 4.0.
> Most of them are waiting for review and commit.
> > - There are <10 bugs on Jira for the first cut of the release.
> > - Upgrade from previous versions is currently being worked on.  Scheduled
> to be done by the end of the week.
> >
> > License Readiness
> > - Majority of the VM configuration issues have been resolved.  There is one
> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> > - Technology export issues are still be worked on by David Nalley and AFS
> legal.  This may be a blocking issue.
> > - Licenses need auditing.
> >
> > Doc Readiness
> > The current plan for docs is to write an INSTALL.TXT to give instructions on
> how to install from source.  All docs will be generated to a living document
> that continues to improve past the release.  The link to this living document is
> to be determined.
> >
> > TODO:  Docs need help on the new features in the 4.0 release.  Specifically
> we need help with Niciria Integration and Caringo documentation.
> >
> > QA Status
> > QA is proceeding through the test cycle.  It is currently at 45% of completion.
> The number of bugs generated from the tests have been minimum so the
> quality of the release currently looks pretty good.
> >
> > Release Plan
> > - The current plan is for QA to complete its test cycle between 9/26-9/28.
> > - When QA decides the test cycle is read, we will cut a RC1 release.
> > - We are currently pushing to clear bugs generated from the test cycle asap.
> > - After all P1 and P2 bugs are cleared, 4.0 release will be submitted for
> approval to announce.
> >
> > --Alex
> >
> >

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

Alex,

I've been cutting "RC" source code bundles, and have been numbering
them as RCx (Wednesday will be RC3).

Do you think I should switch to a more informal scheme until we have
something to vote on officially?

- chip

Sent from my iPhone.

On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:

> Hi All,
>
> I've been reminded that I've neglected to update the community on the current status for CloudStack 4.0.  I apologize for that oversight.  From now til the actual release, I will give a daily update on the status.  If you feel anything is missing, please let me know and I'll try to include them on the next update.
>
> Summary
> As of 9/24/2012, CloudStack 4.0 release has past code freeze stage (over three weeks ago).  A source code branch has been forked and is called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
>
> Feature List
> There are two features that missed the 4.0 release.  Auto-Scaling and Brocade Plugin.  Both are due to having significant code changes due past the code freeze date.
>
> Code Readiness
> - There are ~5 code related reviews on the review board scheduled for 4.0.  Most of them are waiting for review and commit.
> - There are <10 bugs on Jira for the first cut of the release.
> - Upgrade from previous versions is currently being worked on.  Scheduled to be done by the end of the week.
>
> License Readiness
> - Majority of the VM configuration issues have been resolved.  There is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> - Technology export issues are still be worked on by David Nalley and AFS legal.  This may be a blocking issue.
> - Licenses need auditing.
>
> Doc Readiness
> The current plan for docs is to write an INSTALL.TXT to give instructions on how to install from source.  All docs will be generated to a living document that continues to improve past the release.  The link to this living document is to be determined.
>
> TODO:  Docs need help on the new features in the 4.0 release.  Specifically we need help with Niciria Integration and Caringo documentation.
>
> QA Status
> QA is proceeding through the test cycle.  It is currently at 45% of completion.  The number of bugs generated from the tests have been minimum so the quality of the release currently looks pretty good.
>
> Release Plan
> - The current plan is for QA to complete its test cycle between 9/26-9/28.
> - When QA decides the test cycle is read, we will cut a RC1 release.
> - We are currently pushing to clear bugs generated from the test cycle asap.
> - After all P1 and P2 bugs are cleared, 4.0 release will be submitted for approval to announce.
>
> --Alex
>
>

Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

Alex,

I've been cutting "RC" source code bundles, and have been numbering
them as RCx (Wednesday will be RC3).

Do you think I should switch to a more informal scheme until we have
something to vote on officially?

- chip

Sent from my iPhone.

On Sep 24, 2012, at 10:27 PM, Alex Huang <Al...@citrix.com> wrote:

> Hi All,
>
> I've been reminded that I've neglected to update the community on the current status for CloudStack 4.0.  I apologize for that oversight.  From now til the actual release, I will give a daily update on the status.  If you feel anything is missing, please let me know and I'll try to include them on the next update.
>
> Summary
> As of 9/24/2012, CloudStack 4.0 release has past code freeze stage (over three weeks ago).  A source code branch has been forked and is called 4.0.  Nightly build is running on Jenkins on the 4.0 build.
>
> Feature List
> There are two features that missed the 4.0 release.  Auto-Scaling and Brocade Plugin.  Both are due to having significant code changes due past the code freeze date.
>
> Code Readiness
> - There are ~5 code related reviews on the review board scheduled for 4.0.  Most of them are waiting for review and commit.
> - There are <10 bugs on Jira for the first cut of the release.
> - Upgrade from previous versions is currently being worked on.  Scheduled to be done by the end of the week.
>
> License Readiness
> - Majority of the VM configuration issues have been resolved.  There is one remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
> - Technology export issues are still be worked on by David Nalley and AFS legal.  This may be a blocking issue.
> - Licenses need auditing.
>
> Doc Readiness
> The current plan for docs is to write an INSTALL.TXT to give instructions on how to install from source.  All docs will be generated to a living document that continues to improve past the release.  The link to this living document is to be determined.
>
> TODO:  Docs need help on the new features in the 4.0 release.  Specifically we need help with Niciria Integration and Caringo documentation.
>
> QA Status
> QA is proceeding through the test cycle.  It is currently at 45% of completion.  The number of bugs generated from the tests have been minimum so the quality of the release currently looks pretty good.
>
> Release Plan
> - The current plan is for QA to complete its test cycle between 9/26-9/28.
> - When QA decides the test cycle is read, we will cut a RC1 release.
> - We are currently pushing to clear bugs generated from the test cycle asap.
> - After all P1 and P2 bugs are cleared, 4.0 release will be submitted for approval to announce.
>
> --Alex
>
>