incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenfeng Liu <liush...@gmail.com>
Subject Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...
Date Fri, 20 Jul 2012 05:52:50 GMT
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