incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <sudha.ponnaga...@citrix.com>
Subject RE: [ASFCS41] Proposed schedule for our next release
Date Mon, 05 Nov 2012 15:19:01 GMT
+1 on timeline from Kevin

QA cycles seem to be ok except that I would like to get QA involved right away from the beginning
of the release cycles. 

But I highly doubt that dev can be done by 2012-12-31 - Thanks Giving /Christmas /New Year
and Indian festival holidays would account for majority of the delays from dev side. This
would push dev timelines  in to QA hardening cycles which takes away stability of code to
run final regression cycles.  This date would be impossible in my opinion to complete dev
work. We should consider extending it as proposed by Kevin. 

Below is how I see QA cycles gets executed in the structure provided by chip:
 1 full cycle of QA done which covers 
- full new feature coverage
- high impacted legacy features
- automated regression coverage
- moderate coverage of defect closures
This would align with  defect fix cycle  ( from chip's proposal -  2013-01-01 through 2013-01-30
  Doc Updates Testing/Bug Fixes (testing against jenkins artifacts)

2nd cycle
- highly impact areas where code has been destabilized due to defect fixes
- regression coverage for selected areas to build confidence
Aligns with final regression cycle end ( from chip's proposal  - 2013-02-01 through 2013-02-22
  Translation Development and Integration (should be ongoing, but focused effort)
  Final regression testing / bug fixes / doc fixes )

I would like to review scope and provide QA Master test plan once we have finalized scope
and release timelines on 4.1

Thanks
/sudha

-----Original Message-----
From: Noah Slater [mailto:nslater@apache.org] 
Sent: Monday, November 05, 2012 6:54 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [ASFCS41] Proposed schedule for our next release

That's cool. The times involved were much less important than the general structure of the
proposal. (And it is just that, a proposal. If y'all can think of better ways to do this,
I am excited to hear them. This is an area I'm trying to figure out myself.)

On 5 November 2012 14:39, Kevin Kluge <Kevin.Kluge@citrix.com> wrote:

> This schedule gives us only 7 weeks from today to develop features, 
> and of that time most committers will be offline for a week or two due 
> to holidays.  Some features have already been developed, but I don't 
> think, relatively speaking, much has been done in the past few weeks.  
> Even if we adopt 4 month release cycles (as in the other thread) we'd 
> still get 4 months of feature development, unlike this proposal where dev time is quite
> small.   I'd prefer to push this release to have at least 4 months of dev.
>  This better spreads out the cost of regression testing, doc reviews, 
> etc and be more efficient for the project.  So I'd propose to take the 
> dates you listed and add two months to all of them.
>
> -kevin
>
>
> > -----Original Message-----
> > From: Chip Childers [mailto:chip.childers@sungard.com]
> > Sent: Saturday, November 03, 2012 9:32 AM
> > To: <cloudstack-dev@incubator.apache.org>
> > Subject: Re: [ASFCS41] Proposed schedule for our next release
> >
> > On Nov 3, 2012, at 12:06 PM, Noah Slater <nslater@apache.org> wrote:
> >
> > > On 2 November 2012 03:07, Chip Childers 
> > > <chip.childers@sungard.com>
> > wrote:
> > >
> > >> First, note the subject tag of "[ASFCS41]".  I'm making 2 
> > >> assumptions right now.  First, that we should adopt semantic 
> > >> versioning for our versioning scheme.  Second, that our next 
> > >> feature release will be backward compatible with 4.0.0-incubating.
> > >
> > > Cool. Which would make it 5.0, then?
> > >
> >
> > Nope, 4.1.0. Key statement: "will be"
> >
> > >
> > >> * Developers, does a 2 month window to get new stuff into a 
> > >> master for the feature release work?  Do you think that this is 
> > >> enough time to deal with the bugs that come out of testing?
> > >
> > >
> > > You might want to consider striping your releases, so you do a 
> > > feature release, then two bug fix releases.
> > >
> > Yup, thats what we have been discussing. I'm only talking about the
> feature
> > release in this thread.
> >
> > > Consult the following WIP for more of an idea of what I mean:
> > >
> > > http://wiki.apache.org/couchdb/Roadmap_Process
> > >
> > > Quoted from that page (which has diagrams, so you're missing out):
> > >
> > > Feature
> > >
> > >
> > >
> > > Every three months, we will release a new feature release.
> > >
> > >
> > >
> > > These releases will contain any new features in them since the 
> > > last
> > >> release, as well as any bugfixes.
> > >
> > >
> > >
> > > If the release contains breaking changes, it will be a major 
> > > release, else
> > >> it will be a minor release.
> > >
> > >
> > >
> > > Each feature release will be supported for 12 months.
> > >
> > >
> > >
> > > Therefor, at any one particular time, there should be four 
> > > supported
> > >> feature releases.
> > >
> > >
> > >
> > > Bugfix
> > >
> > >
> > >
> > > Every month in-between the feature releases, we will release 
> > > bugfix
> > >> releases.
> > >
> > >
> > >
> > > We will do a bugfix release for any supported feature releases, 
> > > where
> > >> bugfixes are available.
> > >
> > >
> > >
> > > This may involve backporting the bugfix to four supported feature
> releases.
> > >
> > >
> > > Just an idea at this stage, even for CouchDB.
> > >
> > > But would be interested in hearing how you think it might work for 
> > > us,
> here?
> > >
> > >
> > > --
> > > NS
>



--
NS

Mime
View raw message