On 5/11/12 2:46 PM, Rob Weir wrote:
On Fri, May 11, 2012 at 3:26 AM, Jürgen Schmidt
<[email protected]> 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.
sure when we have updates we can include them. Everything on demand and
based on requests/communicaiton.
- 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...)
yes, I think so. We should create Issues for these things as well,
discuss on ooo-dev and put it on the wiki
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Feature+Planning
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?
I do it exactly this way but when somebody prefers to create a patch,
apply it on trunk and test it there it would be also fine. Keeping in
mind that we have build bots for trunk that can detect potential build
problems early.
Juergen
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.
-Rob
Juergen
