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 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 > > > > >
