Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of liushenf@gmail.com designates
 74.125.82.43 as permitted sender)
MIME-Version: 1.0
Date: Wed, 18 Jul 2012 15:02:33 +0800
Message-ID: 
 <CANQgRaZrvGyJf=OBbr88sgvw2y1BW1uR9NS03FsGwR3p0i=a4w@mail.gmail.com>
Subject: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...
From: Shenfeng Liu <liushenf@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e6d7e4b64be1ca04c5153f1d

--0016e6d7e4b64be1ca04c5153f1d
Content-Type: text/plain; charset=ISO-8859-1

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.
(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.

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.
(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.
(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.

Any comments?

- Simon

--0016e6d7e4b64be1ca04c5153f1d--