incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Grignon <kevingrignon...@gmail.com>
Subject Re: [RELEASE][3.5] Process thinking - defect&feature rules, iteration...
Date Tue, 24 Jul 2012 19:55:00 GMT
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. 



> - 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
View raw message