KG01 - see comments inline. On Jul 21, 2012, at 12:07 PM, Shenfeng Liu <[email protected]> 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 <[email protected]> > >> KG01 - See comments inline. >> >> On Jul 20, 2012, at 4:59 PM, Shenfeng Liu <[email protected]> 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 <[email protected]> >>> >>>> 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 <[email protected]> >> 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 <[email protected]> >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>
