[Libreoffice] Release criteria

[Sophie Gautier]

On 13/12/2010 13:57, Petr Mladek wrote:
> Hi,
>
> ah, I have somehow missed this mail.
>
> Sophie Gautier píše v Ne 05. 12. 2010 v 20:49 +0300:
>> Hi Andrea, all,
>> On 05/12/2010 20:39, Andrea Pescetti wrote:
>>> On 26/11/2010 Petr Mladek wrote:
>>>> http://wiki.documentfoundation.org/Release_Criteria
>>>> Feel free to update it or propose improvements. Especially, I am not
>>>> sure about bugs in localizations.
>>>
>>> So a major change with respect to the OpenOffice.org release process
>>> would be that no explicit approval is needed for localized versions.
>>
>> Imho, this should still be needed. Manuals tests are currently developed
>> on the wiki and they should be run on each language for approval of the
>> build to be elected as stable.
>>
>>> This is probably related to the multi-language build model, where you
>>> don't want to wait for 20 or so explicit approvals in order to release
>>> the English version, but still distributing possibly untested software
>>> does not seem very good to me: I did see cases at OpenOffice.org where
>>> only one localized version would not start, or would have blocking
>>> issues.
>>
>> I agree and this is why the non tested build were left on RC state. We
>> should not change this or we will miss some quality.
>
> Hmm, we want the multilang build because of the reason mentioned in my
> other reply to this thread.
>
> I think that it is not realistic to wait for approval from all the
> localizations teams

Not all, but I'm not sure it's good to provided non tested builds at all.
>
> LibO-3.3-RC1 has been available since December 6. RC2 will not be sooner
> than December 15. So, you should have time to nominate blockers until
> December 22. So, you should have 18 days for testing.
>
> The idea is that the fixes between RCs must be safe and reviewed, so
> they should not trigger the whole QA process.

Do you count the l10n QA process in this delay? I hope it's the only 
time we have to provide some strings in a so short time without the 
chance to review it in the product ;)

Well, I think we have to refine the process for the next version :
- feature freeze
- last l10n integration
- testing
- code freeze
- last code fixes
- last l10n fixes
- rc -> needed rc fixes without l10n fixes
- final

And give enough time between and a head up at each step to make every 
body happy.

Kind regards
Sophie