incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenfeng Liu <liush...@gmail.com>
Subject Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...
Date Wed, 25 Jul 2012 03:36:38 GMT
Kevin,
  Please see my comments below. Thanks!

- Simon

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

> KG01 - see comments inline.
>
> On Jul 21, 2012, at 12:07 PM, Shenfeng Liu <liushenf@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 <kevingrignon.oo@gmail.com>
> >
> >> KG01 - See comments inline.
> >>
> >> On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <liushenf@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 <leiw@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 <liushenf@gmail.com>
> >> wrote:
> >>>>
> >>>>> Juergen,
> >>>>> Thanks for your comments!
> >>>>> My thoughts below...
> >>>>> And I updated the 3.5 Release Planning
> >>>>> wiki<
> >>>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning
> >>>>>> with
> >>>>> a draft of the defect/feature rule. Could you and QE team review
and
> >>>>> give comments?
> >>>>> Again, it is not only related to developers, but also testers and
> >> other
> >>>>> contributors on how to collaborate in 3.5. So I'd like to hear more
> >>>>> comments. e.g. from Yan Ji and other QE members...
> >>>>> And translation process is a very important part, but I'm not quite
> >>>>> familiar...
> >>>>>
> >>>>> - Simon
> >>>>>
> >>>>>
> >>>>> 2012/7/18 J├╝rgen Schmidt <jogischmidt@googlemail.com>
> >>>>>
> >>>>>> On 7/18/12 9:02 AM, Shenfeng Liu wrote:
> >>>>>>> Hi, all,
> >>>>>>> I made some update on the AOO 3.5 Release Planning wiki
Juergen
> >>>>>> created:
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning
> >>>>>> .
> >>>>>>>
> >>>>>>> And besides proposing contents in the High Level Overview
table, I
> >>>>>> think
> >>>>>>> we should also think about the release process. And below
are what
> in
> >>>>> my
> >>>>>>> mind:
> >>>>>>>
> >>>>>>> 1. Defect/Enhancement rule
> >>>>>>>
> >>>>>>> In 3.5, there will be not only defects, but also some feature
> >>>>>> enhancements
> >>>>>>> that need relatively bigger development efforts. The 3.5
release
> >>>> circle
> >>>>>>> will also be longer than 3.4.1. And more contributors will
> >>>>> participate, I
> >>>>>>> believe. So it is very important to build up a good traceability,
> so
> >>>>> that
> >>>>>>> we can query out the project status automatically, but not
rely on
> >>>>>> people's
> >>>>>>> input in wiki.
> >>>>>>> To make it happen, we need to define some rules in Bugzilla
for:
> >>>>>>>
> >>>>>>> (1) Defect/Enhancement creating. e.g. against which Version,
define
> >>
> >> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>

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