Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jancasacondor@gmail.com
 designates 209.85.219.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <508B02CA.2040802@wtnet.de>
References: <508A369B.60301@apache.org>
	<CAP-ksoj4oauWT1HrU-eWnLonx+Kkh4LcuyBg=YwRNbiwycvVCw@mail.gmail.com>
	<508ACBB7.7020908@apache.org>
	<508AFB63.7000700@wtnet.de>
	<CAK2iWdQXYVWG_2rFk1MfEtgwWz2Dx9qtrKX4-jtaYD3gr9fnGA@mail.gmail.com>
	<508B02CA.2040802@wtnet.de>
Date: Fri, 26 Oct 2012 23:46:12 +0200
Message-ID: 
 <CAK2iWdRaG-ooH07O_cfWbF1LLnwfBi3KsyPG0q8mBhMmn172-w@mail.gmail.com>
Subject: Re: [RELEASE] Releasing new languages for 3.4.1
From: jan iversen <jancasacondor@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec54a32d696e02904ccfd3f10

--bcaec54a32d696e02904ccfd3f10
Content-Type: text/plain; charset=ISO-8859-1

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.

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

--bcaec54a32d696e02904ccfd3f10--