incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: [RELEASE] Releasing new languages for 3.4.1
Date Fri, 26 Oct 2012 22:08:05 GMT
Am 10/26/2012 11:46 PM, schrieb jan iversen:
> On 26 October 2012 23:38, Marcus (OOo)<marcus.mail@wtnet.de>  wrote:
>
>> Am 10/26/2012 11:20 PM, schrieb jan iversen:
>>
>>   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 !
>>>
>>
>> Right
>>
>>
>>   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
>> plan.
>
> +1
>
>>
>>
>>   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 think it is not really used (I might be wrong) but with frequent releases
> we should use it intensively, because today those who submit a bug must be
> pretty disappointed, I looked at a bug the other day, dated 2007 which are
> still a bug.

Ah, now I get it.

This problem comes from the migration from the old OOo's Issuezilla to 
Apache's Bugzilla. Here the old field disappeared and the information 
was not shown in Bugzilla.

The field you see now was added afterwards and has to be filled newly.

Marcus



>>   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
>> work.
>>
> I think I did not express it correctly, resources tend to be used for short
> term targets (next release, high motivation, lets make it folks, and after
> that we do all the rest).
>
>
>>
>> Marcus
>>
>>
>>
>>
>>     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.
>>>>
>>> +1 THAT IS IMPORTANT...that is to me a major difference to commercial
> products !!!!
>
>>
>>>> Marcus

Mime
View raw message