incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: [RELEASE] Releasing new languages for 3.4.1
Date Fri, 26 Oct 2012 21:38:18 GMT
Am 10/26/2012 11:20 PM, schrieb jan iversen:
> On 26 October 2012 23:06, Marcus (OOo)<>  wrote:
>> Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:
>>   Rob Weir wrote:
>>>> 1) release new languages via lang packs only for now
>>>> 2) release full installs, but for only these new languages
>>> I don't see a big difference between a langpack and a full install in
>>> this case, so I'd go for full installs, unless releasing langpacks helps
>>> in communicating that these are "late" additions and that full installs
>>> will come with the next release.
>>>   Can we really skip the release process? PO files == source, right?
>>> Yes, not exactly but quite (PO files are not taken verbatim into source,
>>> but they are imported and influence resource files which are in the
>>> source tree).
>>>   Maybe a question for legal-discuss if we're not certain.
>>> If in the end we have consensus on releasing new languages for 3.4.1
>>> instead of making a new release, indeed we will ask.
>>>   How do we want to handle this on an ongoing basis? New point release
>>>> for every new language? Every 5 new languages? It is certainly good
>>>> for volunteers to get the encouragement of a fast turnaround for their
>>>> work. But this is the same for a C++ programmer.
>>> There are big differences here, that are also the reason for me to
>>> consider releasing these new languages as soon as possible:
>>> - A translation is often done by a team; if we can publish it
>>> immediately, the team can the be involved in other activities like
>>> revamping the N-L website, local promotion and so on; if we wait too
>>> much, we risk to have no volunteers for the following release.
>> Really? I'm not that convinced that this would happen. When we communicate
>> from the beginning when new loalizations will be released then everybody
>> should be able to understand and handle this.
>>   - Releasing a new language is totally risk-free: a new language can't
>>> break functionality in OpenOffice, while any feature could have bugs and
>>> needs more qualified testing.
>> Besides the comment from Jan I remember a case from the old OOo project.
>> There were some translations for the names of Calc functions that got the
>> same name but had to get (slightly) different names. The result was that
>> there were 2-3 sum, 2-3 average, etc. functions. This was also - more or
>> less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I
>> don't remember anymore.
>> So, the risk of new languages may not be high but I wouldn't say it's
>> totally risk-free.
>>   In the end, I wonder whether the best solution is to get into a steady
>>>> release cycle of quarterly releases (every 3 or 4 months)?
>> +1
>> IMHO a regular release schedule is a very good idea. Then everybody can
>> cope with this, can see when the next version will come and we can plan
>> with a regular release plan (when to branch, freeze, localize, etc.).
>> Of course the timeframe will need some discussions to find the right one.
>> Previously it was tried to release every 6 months a new major release and
>> every 6 months a point release. So, with overlapping there was a new
>> release every 3 month. Maybe a good timeframe to continue?
> +1 to a relatively fixed time frame for new releases. Not only developers
> benefit from that but also end-users !


> However do we have the logistic in place to handle ideas/request/bug fixes
> with these short intervals. It would mean (in my opinion) that we have an

OK, maybe the following fitts better to our current situation. Every 6 
months a new major release and a point release on demand - enough new 
languages, urgent/severe bugfixes; that means outside a regular release 

> open catalog (new development) for 2-3 releases and have to prioritize
> within a limited timeframe what goes where ? We should also consider to
> apply a field in bugzilla, "targeted for version".

That's already existing. Just look for the "Target Milestone" field.

> I really like the idea, but it has a tendency of killing long term
> developments, because they are hard to put into this framework, so we need
> something in the middle.

When we plan which new and planned feature goes into what release should 


>>   This could be a solution too. In this case we would have the problem of
>>> choosing what to translate (3.4 or 3.5? probably we would ask new
>>> volunteers to focus on strings that will be in the next release, even
>>> though they aren't frozen yet).
>> In any case we should continue to release new languages; regardless if
>> major or point versions.
>> Marcus

View raw message