incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@gmail.com>
Subject Re: [RELEASE] Releasing new languages for 3.4.1
Date Wed, 31 Oct 2012 13:42:34 GMT
On 10/31/12 12:18 PM, jan iversen wrote:
> I do not understand the release discussion assuming juergen  is right.

or I have misunderstand your question ;-) I think we as AOO can define
how we do QQ and how we want to ensure the quality of our releases.
Besides the functional aspects here we have to follow some Apache rules
how releases have to be made.

Juergen

 why
> don't we ask each team to send a mail confirming they have made QA then we
> would release the language packs officially (at least this time)
> 
> this would also give us time to discuss the ideal situation.
> 
> juergen: you will (hopefully) soon get an extra pair of hands to help!
> Den 31/10/2012 11.10 skrev "Jürgen Schmidt" <jogischmidt@gmail.com>:
> 
>> On 10/30/12 4:22 PM, jan iversen wrote:
>>> Question: Is there a rule in "the apache way" defining who can do QA, or
>> is
>>> it totally up to the single teams ?
>>
>> It's up to the teams I think
>>
>>>
>>> Do we use the "review statistic" in pootle to anything, it seems actually
>>> quite clever.
>>
>> we don't make use of it right now and I have to confess that I haven't
>> really looked in it yet because of the lack of time.
>>
>>
>> Juergen
>>
>>>
>>> Jan.
>>>
>>> On 30 October 2012 16:17, Jürgen Schmidt <jogischmidt@gmail.com> wrote:
>>>
>>>> On 10/30/12 2:46 PM, Rob Weir wrote:
>>>>> On Oct 30, 2012, at 9:03 AM, RGB ES <rgb.mldc@gmail.com> wrote:
>>>>>
>>>>>> 2012/10/30 Jürgen Schmidt <jogischmidt@gmail.com>
>>>>>>
>>>>>>> On 10/27/12 3:57 AM, Rob Weir wrote:
>>>>>>>> On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir <robweir@apache.org>
>> wrote:
>>>>>>>>> On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher <
>> dave2wave@comcast.net>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote:
>>>>>>>>>>> ...  it would probably allow to skip the release
process and
>>>> voting,
>>>>>>> since we would merely be adding 3-5 binary artifacts (built for
>>>> different
>>>>>>> platforms).
>>>>>>>>>>
>>>>>>>>>> It is an interesting question if we should only vote
for source
>>>>>>> releases. Certainly these are the only "official" release. I
think
>>>> that the
>>>>>>> practice is to vote for binary packages as well. Clearly those
have a
>>>>>>> different bar. It is worth discussing, but I am inclined to think
>> that
>>>> we
>>>>>>> do need to VOTE on these packages, but in this case we are voting
at
>> a
>>>>>>> certain level of trust for the packager and translations.
>>>>>>>>>
>>>>>>>>> But the point is we need to release the source that the
binaries
>>>>>>>>> depend on, where that source is from this project.
>>>>>>>>>
>>>>>>>>> It would be one thing if we were just releasing a new
platform port
>>>> of
>>>>>>>>> existing source packages.  But we're not.
>>>>>>>>>
>>>>>>>>> We're talking about new translations resources, where
such
>> resources
>>>>>>>>> are in SVN and are required as part of the build process
in order
>> to
>>>>>>>>> build the localized binaries.  No downstream consumer
of the source
>>>>>>>>> will be able to build these localizations without having
access to
>>>> the
>>>>>>>>> translated resources.  Therefore these resources should
be
>> reviewed,
>>>>>>>>> voted on and released.
>>>>>>>>>
>>>>>>>>> Remember, the translations are non-trivial creative works,
>>>>>>>>> translations of not only UI strings, but larger text
passages from
>>>> the
>>>>>>>>> help files.  They are under copyright and made available
under
>>>>>>>>> license.  So we need to do our due diligence via the
release
>> process
>>>>>>>>> before we distribute such materials.
>>>>>>>>
>>>>>>>> Should say, "before we distribute such materials in source
OR source
>>>>>>>> and binary form".  The issues are the same.
>>>>>>>>
>>>>>>>> Remember, the source package is canonical.  I'm surprised
to hear
>> talk
>>>>>>>> now of releasing only binaries.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I am still not sure how we can address this but I would really
like
>> to
>>>>>>> make new translations available as soon as possible.
>>>>>>>
>>>>>>> What about the idea to prepare official developer language packs
>> based
>>>>>>> on the AOO34 branch and where the new translations are already
>> checked
>>>>>>> in? If we decided later to release a 3.4.2 because of other critical
>>>>>>> security or general bugfixes the new translations becomes included
>>>>>>> automatically.
>>>>>>>
>>>>>>> The new language packs will have the same version number 3.4.1
but
>> are
>>>>>>> not officially released and are available via the snapshot page.
>>>>>>>
>>>>>>> When we reach a state where we have "release" build bots, we
can
>>>>>>> probably trigger much easier a complete respin with the same
product
>>>>>>> version but based on a new revision number including the new
>>>> translations.
>>>>>>>
>>>>>>> Juergen
>>>>>>
>>>>>> +1. I like the idea. We can put on the download page a link to
>>>> "additional
>>>>>> untested language packs" and add "these language packs are being
>>>> prepared
>>>>>> for the next AOO version, but you can use them right now" or something
>>>> like
>>>>>> that.
>>>>>>
>>>>>
>>>>> Even beta releases are still releases from the Apache perspective and
>>>>> still require that we go through a release vote.
>>>>>
>>>>> Why are we trying so hard to avoid this process?  It isn't that hard.
>>>>> And it is important that we follow the procedures before putting the
>>>>> "Apache" label on software we make available to the public.
>>>>
>>>> I don't see that we try to avoid this process. But with with a certain
>>>> level of QA we have to test the new language builds anyway.
>>>>
>>>> Means in detail we can start with the snapshot builds and can test it.
>>>> If we get no complains we can create a new src release (a respin if
>>>> possible) where the new translations are included. And we upload only
>>>> the new src release and the new language packs. I would be also fine
>>>> with uploading full install sets but this is matter of taste and space.
>>>>
>>>> Juergen
>>>>
>>>>
>>>>>
>>>>> -Rob
>>>>>
>>>>>
>>>>>> Regards
>>>>>> Ricardo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> -Rob
>>>>>>>>
>>>>>>>>> -Rob
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Dave
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>>
> 


Mime
View raw message