Rob Weir wrote:
On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna
<[email protected]> wrote:
Rob Weir wrote:

On Sun, Sep 23, 2012 at 10:13 AM, Shenfeng Liu <[email protected]> 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+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".

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




Reply via email to