2012/9/26 Keith N. McKenna <keith.mcke...@comcast.net> > Shenfeng Liu wrote: > >> 2012/9/24 Keith N. McKenna <keith.mcke...@comcast.net> >> >> Rob Weir wrote: >>> >>> On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna >>>> <keith.mcke...@comcast.net> wrote: >>>> >>>> Rob Weir wrote: >>>>> >>>>> >>>>>> On Sun, Sep 23, 2012 at 10:13 AM, Shenfeng Liu <liush...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> > <snip> > > >>>>>>> Maybe also start a "release notes" page on the wiki. Whenever a new >>>>>> feature or important bug fix is added to the trunk also add something >>>>>> to the release notes. If something can be show with a "before and >>>>>> after" screen shot, include that. This might be easier than waiting >>>>>> until the end to prepare the release notes. >>>>>> >>>>>> -Rob >>>>>> >>>>>> >>>>>> - Simon >>>>>>> >>>>>>> >>>>>> >>>>>> Rob; >>>>>> >>>>> >>>>> A Release Notes page already exists or 3.5 and one or 4.0 can be easily >>>>> added. The complication I see here is since we have not decided whether >>>>> the >>>>> next release will be 3.5 or 4.0 that would require adding it in two >>>>> places. >>>>> I see that as a lot of overhead at this point. >>>>> >>>>> >>>>> IMHO, the name is not so important. Everything in the trunk goes into >>>> the next release. Nothing not in the trunk goes into the next >>>> release. So if we want a wiki page that is called "Release notes for >>>> AOO Target January 2013" then it would be sufficient. Just describe >>>> significant changes there made in the trunk. Maybe in the end we call >>>> it "Apache OpenOffice 2013", or "Apache OpenOffice Adventitious >>>> Armadillo" or something like that. That decision can come later. >>>> >>>> -Rob >>>> >>>> >>>> In that case lets use the existing 3.5 Release Notes as Armin has >>> already >>> put a number of entries in there the "name can be change to protect the >>> innocent later". >>> >>> >> +1 to use the existing 3.5 Release Notes wiki. >> >> And I just made a query in BZ, for defects fixed after 3.4 (May 8), and >> excluded (1) some Products as qa, www, (2) those Target Milestone set to >> 3.4.1, and (3) Issue Type not in (DEFECT, FEATURE, ENHANCEMENT). And I got >> about 500 results. I picked some of them in the list and believe there are >> still many items need to be taken out, e.g. those fixed 1 year ago, but >> just validated recently. So I think I can quickly go through them, and for >> those who are really fixed/implemented in trunk after 3.4 and not in >> 3.4.1, >> I will set the Target Milestone to AOO 3.5.0. And this list can be a base >> for our release notes. How do you think? >> >> Another thing is that we need to define a test plan for the milestone >> build, which can be a lightweight regression test suite. The plan can be >> published on a wiki, and executed against very milestone build. >> I agree with Juergen that we should start as early as possible. While I >> still hope to get the confirmation from our QE team, since IMO they are >> the >> key to this plan. :) >> >> - Simon >> >> Simon; > > Thank you for doing that. One question is the query public and if so where > is it? My idea was not only to use it as a base for the release notes, but > to also link to it from the release notes for those who are interested in a > particular bug and also in place of listing every bug in the release notes > that was fixed. >
I created a query named TargetTo350AllFixed and shared it. Ideally it can be the base for the release notes. But the problem is, as I mentioned above, people didn't set this field correctly for all issues. Some fixes in trunk didn't set the Target Milestone, and some issues last changed 1 years ago are in the list (which is so strange, because there is even no AOO 1 at that time...) So I need to go through the list, and correct this field. I think we should force the input to this field when an issue is resolved. - Simon > >> >> >>> Regards >>> Keith >>> >> <snip> > > >
