On May 11, 2012, at 5:46 AM, 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. > >> - 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...)
Also cleanup of NOTICE and LICENSE to both fix eol issues and improve the flow. Regards, Dave > >> >> 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. > > -Rob > >> Juergen
