incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lei Wang <l...@apache.org>
Subject Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...
Date Fri, 20 Jul 2012 06:14:30 GMT
I add some items for Calc application for 3.5 plan in 3.5 Release Planning
wiki<
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning
>

If there are anything which must be in 3.5 for Calc, please discuss it here
or put it in the list in the planning wiki.

On Fri, Jul 20, 2012 at 1:52 PM, Shenfeng Liu <liushenf@gmail.com> wrote:

> Juergen,
>   Thanks for your comments!
>   My thoughts below...
>   And I updated the 3.5 Release Planning
> wiki<
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning
> >with
> a draft of the defect/feature rule. Could you and QE team review and
> give comments?
>   Again, it is not only related to developers, but also testers and other
> contributors on how to collaborate in 3.5. So I'd like to hear more
> comments. e.g. from Yan Ji and other QE members...
>   And translation process is a very important part, but I'm not quite
> familiar...
>
> - Simon
>
>
> 2012/7/18 J├╝rgen Schmidt <jogischmidt@googlemail.com>
>
> > On 7/18/12 9:02 AM, Shenfeng Liu wrote:
> > > Hi, all,
> > >   I made some update on the AOO 3.5 Release Planning wiki Juergen
> > created:
> > >
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning
> > .
> > >
> > >   And besides proposing contents in the High Level Overview table, I
> > think
> > > we should also think about the release process. And below are what in
> my
> > > mind:
> > >
> > > 1. Defect/Enhancement rule
> > >
> > > In 3.5, there will be not only defects, but also some feature
> > enhancements
> > > that need relatively bigger development efforts. The 3.5 release circle
> > > will also be longer than 3.4.1. And more contributors will
> participate, I
> > > believe. So it is very important to build up a good traceability, so
> that
> > > we can query out the project status automatically, but not rely on
> > people's
> > > input in wiki.
> > > To make it happen, we need to define some rules in Bugzilla for:
> > >
> > > (1) Defect/Enhancement creating. e.g. against which Version, define of
> > the
> > > Severity/Priority, Keywords needed...
> > > (2) Defect triage. How do we decide if a fix or a feature should be in
> > 3.5
> > > or not? Where do we record our decision (e.g. in Target Milestone, or
> > > Flags)? It will become important when we close to GA, or deliver a
> > > milestone build.
> >
> > all fixes should be allowed to go into a release. And I think all
> > features as well if there are no valid concerns. After having the fixes
> > in a milestone build we can set the target of the issue to 3.5 for
> > example. This will make it clear that it goes into the 3.5, was already
> > part of a milestone build and will be part of further milestones.
> >
>
> Thanks for your comments! I drafted a defect/feature rule in the 3.5
> Release Planning wiki, please review.
>
>
> >
> > We should define the fix integration order. Currently we follow the
> > approach to fix on trunk and merge in the branch on demand. Or fix on
> > branch only if branch specific like branding for example.
> >
>
> For defects and small fixes, I think "fix on trunk and merge in the branch
> on demand" is good approach.
> For feature/enhancements, I prefer them to be completed an pass an
> acceptance testing in a branch firstly, then deliver to trunk.
> For branch specific fixes, as you said, should be only on the specific
> branch.
>
>
> >
> > > (3) Defect fix, patch, review.
> > > (4) Defect verify/close.
> > >
> > > For some rules (e.g. Severity/Priority), we may point to a place with
> > > general rules defined. For some rules specific to 3.5 (e.g. Version,
> > Target
> > > Milestone, Flags), we should write them down in the release planning
> > wiki.
> > > After we defined the rules, QE team can help to define some shared
> > queries
> > > for us to get the project status and todo list.
> >
> > to define and build a common understanding would definitely help all
> > involved parties to track issues and get a better understanding about
> > our releases and what goes in them.
> >
> >
> > >
> > > 2. Iteration and Milestone builds
> > >
> > > Since, as discussed, 3.5 release is likely to last for 6~9 months, I
> > think
> > > it will be good for us to try the iterative development mode, and
> deliver
> > > milestone builds regularly. The milestone builds are dev snapshot
> builds,
> > > not formal release, but contains new bug fixes and enhancements
> > implemented
> > > till the last iteration, and verified to be relatively stable in
> quality
> > by
> > > QE team with a small regression test suite. And the milestone builds
> can
> > be
> > > announced to external for people's try out the new enhancement works,
> > > provide feedback and report issues. And internally, it can help us to
> > > measure the quality regularly, and avoid big quality deviation.
> > > Since we are open community and many of us are volunteers working on
> AOO
> > > with their spare time, it is unlikely for us to apply strict agile
> > > discipline. So I think the process can be some thing like below:
> > >
> > > (1) Define the iterations of 4 weeks or 1 month (or any better
> > > suggestion?), announce the timelines in wiki.
> >
> > a monthly milestone build sound reasonable to me and we have our nightly
> > builds to review fixes more frequently.
> >
> > > (2) 1 week before the iteration, a milestone branch will be created. QE
> > > will do 1 week regression test on it. Dev will fix critical defects
> found
> > > in this branch. Then all the fixes in this milestone branch will be
> back
> > to
> > > 3.5 trunk.
> >
> > it sounds like a tough but good plan if we can achieve it. Definitely
> > worth a try from my perspective.
> >
> > > (3) As a developer, it will be welcome if you can target your work to
> an
> > > iteration. But if you can not finish it before the milestone branch
> > created
> > > (e.g. you are working on an enhancement that will take 2 weeks, and you
> > > just implement 80% by that time), means you can not deliver in this
> > > iteration, then you just keep your work in your branch, and deliver it
> to
> > > 3.5 trunk in the next iteration.
> >
> > Taking into account that we all want a stable and good product I think
> > this is a valid approach and the next iteration is not too far away. And
> > by the way it's always good to split bigger tasks in smaller better
> > maintainable chunks if possible.
> >
>
> I realized that my iteration and milestone proposal may put more pressures
> to QE team. So I think we can do it this way:
> (1) Set monthly as a target.
> (2) If we can not achieve it (not only because the build quality, but also
> can be due to that QE team has no bandwidth to finish the iteration
> regression in time), there can be 2 options: (A) delay for more days for
> this milestone; (B) jump over without announcing this milestone build, and
> target directly to the next milestone. It can be discussed depends on the
> situation then.
>
> Agree with your comments below that we can try 1 or 2 iterations to see how
> it works, then adjust according to the feedback.
>
>
> > I would support such an approach and think we should try it with 3.5. We
> > can adapt it later on when see demand to change or to improve things...
> >
> > Juergen
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message