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 Tue, 25 Sep 2012 14:51:13 GMT
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:
>>>>
>>>>>
>>>>> Hi, all,
>>>>>     After 3.4.1, we are focusing on preparation of the community
>>>>> graduation.
>>>>> But I still want to remind us to take some time to think about our
>>>>> future
>>>>> releases.
>>>>>
>>>>>     We have the discussion early about what 3.5 and 4.0 should look
>>>>> like.
>>>>> If
>>>>> I remember correctly:
>>>>> (1) 3.5 should be more about fidelity, reliability, performance and
>>>>> translation, new platform support...
>>>>> (2) While 4.0, in addition to the same focuses as 3.5, should also add
>>>>> significant UX enhancements (e.g. sidebar, modern UI) and new values
>>>>> (e.g.
>>>>> Accessibility, social integration capability, enhanced installer, new
>>>>> features...). If we make good progress on those items at the same time,
>>>>> we
>>>>> may consider to skip 3.5.
>>>>> (3) There are also more requirements (e.g. fixpack mechanism,
>>>>> simplifying
>>>>> the build structure, OOMXL export, smartArt...) we need  to put into
>>>>> our
>>>>> backlog and consider their priority.
>>>>>
>>>>>     Even we don't need to discuss the solid plan now, but there are
>>>>> already a
>>>>> lot of development activities on the trunk. So I think we need to keep
>>>>> certain track on it. Though it may be too early to set a target date
>>>>> for
>>>>> the next release, but it is important for us to tell more about what
we
>>>>> think the next release should contain.
>>>>>
>>>>>     So I'm suggesting the following:
>>>>>
>>>>> 1. Keep updating the current release planning wiki:
>>>>>        -
>>>>>
>>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>>>> AOO+3.5+Release+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning>
>>>>>        -
>>>>>
>>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>>>> AOO+4.0+Release+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning>
>>>>>      I know it is a little confusing for 2 places to input. But think
>>>>> about
>>>>> the scope we agreed above. You can input to the wiki that you think
>>>>> your
>>>>> work belong to. I personally will monitor both wiki pages.
>>>>>
>>>>> 2. Figure out a better way to manage our release backlog. e.g. set
>>>>> Target
>>>>> Milestone to 3.5 or 4.0 in Bugzilla for what we recommended.
>>>>>
>>>>> 3. Deliver milestone builds to harvest our development fruits. A
>>>>> milestone
>>>>> build is:
>>>>>        (a) a development snapshot that contains the
>>>>> features/enhancements
>>>>> that implemented till now;
>>>>>        (b) passed regression test to ensure no severe defects;
>>>>>        (c) announced on a development wiki;
>>>>>        (d) with documents on the wiki for the list of features and bug
>>>>> fixes
>>>>> in this milestone build (like a release notes).
>>>>>      Since whatever 3.5 or 4.0 sounds to me like some thing in next
>>>>> year
>>>>> or
>>>>> at least close to the end of this year, milestone builds can be light
>>>>> weigh
>>>>> on process to show our development progress, and give people a more
>>>>> clear
>>>>> view on how far are we to the next release.
>>>>>
>>>>>     Looking forward every one's comments!
>>>>>
>>>>>
>>>> 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



>
> Regards
> Keith
>
>
>
>>  I could create a separate page as a sandbox where what you suggest could
>>> be
>>> input, then when the release comes it is just a matter of moving the data
>>> from the sandbox into the formal Release Notes page.
>>>
>>> Regards
>>> Keith
>>>
>>>
>>
>
>

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