[RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Shenfeng Liu <li...@gmail.com>]

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

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Shenfeng Liu <li...@gmail.com>]

Xue Fei,
  Ideally, I want to answer "yes" to your question 1 & 2, and define the
Target Milestone to not only 3.5.0, but also to the level of 3.5.0M1,
3.5.0M2... And ask people to input their plan. However I'm not sure if it
will be too strict for volunteers to do the contribution. Another way can
be checking the actual delivery in the current iteration. We should
encourage developers to set the milestone target, so that QE team can make
the test plan accordingly. But if you check and find a delivery in the
current iteration that not in the list you aware, and if it is too late for
you to change the iteration regression test plan, then we can consider take
one of the following actions:

1. If the delivery has related low risk and manageable impact area, we
might consider to cover it in the next iteration.
2. If the delivery has very high risk or big quality issue (ideally, we
should encourage UT and even FVT by developers to verify the quality before
deliver, so that we can avoid this situation), we can check (1)
(RECOMMENDED) if the delivery can be rollback for now to ensure the quality
of the coming milestone build, and deliver again when the quality issues
resolved in developer's private branch; or (2) If it is very important to
include this delivery, then postpone the schedule waiting for the quality
issue to be resolved, and update the test scope to cover it this time; (3)
Announce the fail of this milestone and jump to next iteration.

  Please see my other comments below. Thanks!

- Simon


2012/7/25 Xue Fei Duan <du...@gmail.com>

> Simon,
> I have several questions:
> 1) we should define feature development and defects fixed plan in one
> iteration, right? it can help developer and tester finish their task in one
> iteration. if we need have iteration development plan review?
>
Please see my comments above.


> 2)if QE reports severity 1& 2 defects, if they all must be fixed in this
> iteration?
>
If the defect is critical like data damage, system crash, that prevent
people to try out the milestone build, then I think it must be fixed for
this milestone, otherwise it fail on quality.


> 3)From my experience, I don't think we can start regression test at the 4th
> week in one iteration, maybe 1st week in next iteration is good choice.
>
I think it is ok. While the truth is that you are still going to do a
regression test every 4 weeks. :P



> Thanks
> -Xue Fei
>
> On Wed, Jul 25, 2012 at 3:55 AM, Kevin Grignon <kevingrignon.oo@gmail.com
> >wrote:
>
> > KG01 - see comments inline.
> >
> > On Jul 21, 2012, at 12:07 PM, Shenfeng Liu <li...@gmail.com> wrote:
> >
> > > Kevin,
> > >  Good suggestion!
> > >  Maybe we can use the Priority field together with the Target Miletone
> > > field. e.g. For an item we propose to 3.5, we set Target Milestone to
> AOO
> > > 3.5, then setup Priority to: P1 for must have, P2 for should have, P3
> for
> > > better to have... ?
> > >
> >
> > KG01 - Prioritizing work is great. Must, should, nice-to-have are simple
> > and clear categories
> > I'm assuming your priority suggestion is independent of a 'backlog'
> target
> > milestone. We need a 'backlog' target to serve as the bucket from which
> we
> > can pull work and create plans.
> >
> >
> >
> > > - Simon
> > >
> > >
> > > 2012/7/20 Kevin Grignon <ke...@gmail.com>
> > >
> > >> KG01 - See comments inline.
> > >>
> > >> On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <li...@gmail.com> wrote:
> > >>
> > >>> Wang Lei,
> > >>> The proposed items look very good! And you can create issues and
> > setting
> > >>> Issue Type as ENHANCEMENT or FEATURE in BZ if they did not exist,
> then
> > >> fill
> > >>> the Task-ID in wiki. Thanks very much for your input!
> > >>>
> > >>> - Simon
> > >>>
> > >>>
> > >>> 2012/7/20 Lei Wang <le...@apache.org>
> > >>>
> > >>>> 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 <li...@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 <jo...@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
> > >>
> > >> KG01 - Can we include a "backlog" or "undefined" fix in version? The
> > >> backlog then allows us to maintain a pool of work items (someday maybe
> > >> list) which can be assigned to iteration/releases moving forward.
> > >>
> > >>
> > >>>> 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
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> >
>

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Xue Fei Duan <du...@gmail.com>]

Simon,
I have several questions:
1) we should define feature development and defects fixed plan in one
iteration, right? it can help developer and tester finish their task in one
iteration. if we need have iteration development plan review?
2)if QE reports severity 1& 2 defects, if they all must be fixed in this
iteration?
3)From my experience, I don't think we can start regression test at the 4th
week in one iteration, maybe 1st week in next iteration is good choice.
Thanks
-Xue Fei

On Wed, Jul 25, 2012 at 3:55 AM, Kevin Grignon <ke...@gmail.com>wrote:

> KG01 - see comments inline.
>
> On Jul 21, 2012, at 12:07 PM, Shenfeng Liu <li...@gmail.com> wrote:
>
> > Kevin,
> >  Good suggestion!
> >  Maybe we can use the Priority field together with the Target Miletone
> > field. e.g. For an item we propose to 3.5, we set Target Milestone to AOO
> > 3.5, then setup Priority to: P1 for must have, P2 for should have, P3 for
> > better to have... ?
> >
>
> KG01 - Prioritizing work is great. Must, should, nice-to-have are simple
> and clear categories.
>
> I'm assuming your priority suggestion is independent of a 'backlog' target
> milestone. We need a 'backlog' target to serve as the bucket from which we
> can pull work and create plans.
>
>
>
> > - Simon
> >
> >
> > 2012/7/20 Kevin Grignon <ke...@gmail.com>
> >
> >> KG01 - See comments inline.
> >>
> >> On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <li...@gmail.com> wrote:
> >>
> >>> Wang Lei,
> >>> The proposed items look very good! And you can create issues and
> setting
> >>> Issue Type as ENHANCEMENT or FEATURE in BZ if they did not exist, then
> >> fill
> >>> the Task-ID in wiki. Thanks very much for your input!
> >>>
> >>> - Simon
> >>>
> >>>
> >>> 2012/7/20 Lei Wang <le...@apache.org>
> >>>
> >>>> 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 <li...@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 <jo...@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
> >>
> >> KG01 - Can we include a "backlog" or "undefined" fix in version? The
> >> backlog then allows us to maintain a pool of work items (someday maybe
> >> list) which can be assigned to iteration/releases moving forward.
> >>
> >>
> >>>> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Shenfeng Liu <li...@gmail.com>]

Kevin,
  Please see my comments below. Thanks!

- Simon

2012/7/25 Kevin Grignon <ke...@gmail.com>

> KG01 - see comments inline.
>
> On Jul 21, 2012, at 12:07 PM, Shenfeng Liu <li...@gmail.com> wrote:
>
> > Kevin,
> >  Good suggestion!
> >  Maybe we can use the Priority field together with the Target Miletone
> > field. e.g. For an item we propose to 3.5, we set Target Milestone to AOO
> > 3.5, then setup Priority to: P1 for must have, P2 for should have, P3 for
> > better to have... ?
> >
>
> KG01 - Prioritizing work is great. Must, should, nice-to-have are simple
> and clear categories.
>
> I'm assuming your priority suggestion is independent of a 'backlog' target
> milestone. We need a 'backlog' target to serve as the bucket from which we
> can pull work and create plans.
>

IMO, ideally, the backlog is in BZ if we really input all the
feature/enhancement requirements in.
e.g. I made a query for the current open issues with type of
ENHANCEMENT/FEATURE, I got a result set of >9000, among them, there are 0
P1, 95 P2. 14 of the > 9000 has Target Milestone set (and none of them are
P1P2).
If we agree it is the right way to trace the backlog, then the next step
will be scan the existing and input new requirements.


>
>
> > - Simon
> >
> >
> > 2012/7/20 Kevin Grignon <ke...@gmail.com>
> >
> >> KG01 - See comments inline.
> >>
> >> On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <li...@gmail.com> wrote:
> >>
> >>> Wang Lei,
> >>> The proposed items look very good! And you can create issues and
> setting
> >>> Issue Type as ENHANCEMENT or FEATURE in BZ if they did not exist, then
> >> fill
> >>> the Task-ID in wiki. Thanks very much for your input!
> >>>
> >>> - Simon
> >>>
> >>>
> >>> 2012/7/20 Lei Wang <le...@apache.org>
> >>>
> >>>> 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 <li...@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 <jo...@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
> >>
> >> KG01 - Can we include a "backlog" or "undefined" fix in version? The
> >> backlog then allows us to maintain a pool of work items (someday maybe
> >> list) which can be assigned to iteration/releases moving forward.
> >>
> >>
> >>>> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Kevin Grignon <ke...@gmail.com>]

KG01 - see comments inline. 

On Jul 21, 2012, at 12:07 PM, Shenfeng Liu <li...@gmail.com> wrote:

> Kevin,
>  Good suggestion!
>  Maybe we can use the Priority field together with the Target Miletone
> field. e.g. For an item we propose to 3.5, we set Target Milestone to AOO
> 3.5, then setup Priority to: P1 for must have, P2 for should have, P3 for
> better to have... ?
> 

KG01 - Prioritizing work is great. Must, should, nice-to-have are simple and clear categories. 

I'm assuming your priority suggestion is independent of a 'backlog' target milestone. We need a 'backlog' target to serve as the bucket from which we can pull work and create plans. 



> - Simon
> 
> 
> 2012/7/20 Kevin Grignon <ke...@gmail.com>
> 
>> KG01 - See comments inline.
>> 
>> On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <li...@gmail.com> wrote:
>> 
>>> Wang Lei,
>>> The proposed items look very good! And you can create issues and setting
>>> Issue Type as ENHANCEMENT or FEATURE in BZ if they did not exist, then
>> fill
>>> the Task-ID in wiki. Thanks very much for your input!
>>> 
>>> - Simon
>>> 
>>> 
>>> 2012/7/20 Lei Wang <le...@apache.org>
>>> 
>>>> 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 <li...@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 <jo...@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
>> 
>> KG01 - Can we include a "backlog" or "undefined" fix in version? The
>> backlog then allows us to maintain a pool of work items (someday maybe
>> list) which can be assigned to iteration/releases moving forward.
>> 
>> 
>>>> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Shenfeng Liu <li...@gmail.com>]

Kevin,
  Good suggestion!
  Maybe we can use the Priority field together with the Target Miletone
field. e.g. For an item we propose to 3.5, we set Target Milestone to AOO
3.5, then setup Priority to: P1 for must have, P2 for should have, P3 for
better to have... ?

- Simon


2012/7/20 Kevin Grignon <ke...@gmail.com>

> KG01 - See comments inline.
>
> On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <li...@gmail.com> wrote:
>
> > Wang Lei,
> >  The proposed items look very good! And you can create issues and setting
> > Issue Type as ENHANCEMENT or FEATURE in BZ if they did not exist, then
> fill
> > the Task-ID in wiki. Thanks very much for your input!
> >
> > - Simon
> >
> >
> > 2012/7/20 Lei Wang <le...@apache.org>
> >
> >> 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 <li...@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 <jo...@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
>
> KG01 - Can we include a "backlog" or "undefined" fix in version? The
> backlog then allows us to maintain a pool of work items (someday maybe
> list) which can be assigned to iteration/releases moving forward.
>
>
> >> 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
> >>>>
> >>>>
> >>>
> >>
>

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Kevin Grignon <ke...@gmail.com>]

KG01 - See comments inline. 

On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <li...@gmail.com> wrote:

> Wang Lei,
>  The proposed items look very good! And you can create issues and setting
> Issue Type as ENHANCEMENT or FEATURE in BZ if they did not exist, then fill
> the Task-ID in wiki. Thanks very much for your input!
> 
> - Simon
> 
> 
> 2012/7/20 Lei Wang <le...@apache.org>
> 
>> 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 <li...@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 <jo...@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

KG01 - Can we include a "backlog" or "undefined" fix in version? The backlog then allows us to maintain a pool of work items (someday maybe list) which can be assigned to iteration/releases moving forward. 


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

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Shenfeng Liu <li...@gmail.com>]

Wang Lei,
  The proposed items look very good! And you can create issues and setting
Issue Type as ENHANCEMENT or FEATURE in BZ if they did not exist, then fill
the Task-ID in wiki. Thanks very much for your input!

- Simon


2012/7/20 Lei Wang <le...@apache.org>

> 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 <li...@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 <jo...@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
> > >
> > >
> >
>

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Lei Wang <le...@apache.org>]

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 <li...@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 <jo...@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
> >
> >
>

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Shenfeng Liu <li...@gmail.com>]

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 <jo...@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
>
>

Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...

[Jürgen Schmidt <jo...@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.

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.

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