incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <jancasacon...@gmail.com>
Subject Re: [RELEASE] Releasing new languages for 3.4.1
Date Fri, 26 Oct 2012 21:20:09 GMT
On 26 October 2012 23:06, Marcus (OOo) <marcus.mail@wtnet.de> 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
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".

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.


>
>  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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message