incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [RELEASE][AOO3.4.1] proposed time schedule and included content
Date Fri, 11 May 2012 12:46:27 GMT
On Fri, May 11, 2012 at 3:26 AM, J├╝rgen Schmidt
<> wrote:
> Hi,
> first of all I am volunteering to act as release manager for 3.4.1 as well
> if our community think it's a good idea.

Thanks for volunteering.

> Independent of the release manager I would like to propose the following
> time schedule and content for a 3.4.1.
> Content
> =======
> - we will support further languages where we have volunteers working on
> translation and where we have ideally 100% UI coverage. I think we should
> focus and balance the support of new languages on demand and completeness.
> Right now we have Finnish and British English with an updated 100% UI
> translation. We can also think about language packs only.

We heard from volunteers on the list for Norwegian and Hebrew
recently.  There should be enough time for time to complete their
translations, if they wish to be included.

> - we will include important and critical bug fixes or necessary changes.
> Bugs/tasks have to be proposed and discussed on the ooo-dev mailing list and
> the issue should be marked with the "3.4.1_release_blocker" flag, concrete
> the "?" value.
> - we will include potential security fixes

So we consider the branch to be frozen and only included new
translations and fixes to "release blocker bugs" and necessary
security patches (which are like release blocker bugs, but are not
discussed on the public list or in Bugzilla).

I assume the thing we found during the 3.4 RC vote can be included as
well, such as the DISCLAIMER files?  (Or maybe we will graduate before
July 31st?   Something to think about...)

> Feature development and less important bugfixes should happen on the trunk
> and will be included in the next major/minor release (3.5, 3.6, 4.0, ...).
> The micro release should include minimal functional changes only.

Should we agree on a merge strategy?  Check into branch and merge into
trunk, for example?

> Time schedule
> =============
> - starting first week of June weekly developer snapshots
> - June 30, potential translation have to be ready to get included
> - July 25, providing RC and start voting
> - July 31, planned release
> QA should we continuously do on the dev builds.

And I assume this testing can be efficient and targeted, since we're
not making any functional additions.  Mainly regression testing.

> Opinions, comments are welcome and appreciated.

It looks reasonable to me.


> Juergen

View raw message