KG01 - See comments inline. On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <liush...@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 <l...@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 <liush...@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 <jogischm...@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 >>>> >>>> >>> >>
