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 Fri, 20 Jul 2012 15:38:41 GMT
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