incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [RELEASE][AOO3.4.1] proposed time schedule and included content
Date Fri, 11 May 2012 21:58:10 GMT

On May 11, 2012, at 5:46 AM, Rob Weir wrote:

> On Fri, May 11, 2012 at 3:26 AM, J├╝rgen Schmidt
> <jogischmidt@googlemail.com> 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


Mime
View raw message