incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenfeng Liu <liush...@gmail.com>
Subject Re: [RELEASE] 3.5, 4.0, fixpack, milestone build...
Date Wed, 26 Sep 2012 02:41:48 GMT
2012/9/26 Keith N. McKenna <keith.mckenna@comcast.net>

> Shenfeng Liu wrote:
>
>> 2012/9/24 Keith N. McKenna <keith.mckenna@comcast.net>
>>
>>  Rob Weir wrote:
>>>
>>>  On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna
>>>> <keith.mckenna@comcast.net> wrote:
>>>>
>>>>  Rob Weir wrote:
>>>>>
>>>>>
>>>>>> On Sun, Sep 23, 2012 at 10:13 AM, Shenfeng Liu <liushenf@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>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message