incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [RELEASE] Releasing new languages for 3.4.1
Date Tue, 30 Oct 2012 15:48:27 GMT
On Tue, Oct 30, 2012 at 11:17 AM, Jürgen Schmidt <> wrote:
> On 10/30/12 2:46 PM, Rob Weir wrote:
>> On Oct 30, 2012, at 9:03 AM, RGB ES <> wrote:
>>> 2012/10/30 Jürgen Schmidt <>
>>>> On 10/27/12 3:57 AM, Rob Weir wrote:
>>>>> On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir <>
>>>>>> On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher <>
>>>> 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
>>>>>> 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
>>>>>> build the localized binaries.  No downstream consumer of the source
>>>>>> will be able to build these localizations without having access to
>>>>>> 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
>>>>>> 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.

It may be worth reviewing this section on "test packages" versus

It is possible to have something less than a release.  We do that, for
example, with snapshots and release candidates.  We could do something
similar with a language pack as well.  But it would need to be an
"internal only" distribution, meaning we do not advertise it with the
user community.  It is just for internal testing.

But if we want to have something available for the public at large to
use, even if we indicate it is "beta" quality, then that is still a

Specific example:  We have 3 or so people helping with the Danish
translation on the L10N list.  If we make a snapshot build for them,
full install or language pack, and advertise it only on that list and
ooo-dev, then I don't think that is a problem.  But we should not make
any user-facing announcements, or website changes to point the public
to the new language pack, until it is an official release.

However, if we want to have a "beta release" of these lang packs, then
this is not hard either:

1) Checked the PO files into the 3.4.x branch

2) Verify that they have correct license headers (assuming PO files
allow a license header)

3) Generate a source package as a diff file of the branch against the
3.4.1 revision

4) Generate the binary packages, perhaps just lang packs, perhaps full installs

5) Sign the source package and binary packages

6) 72 hour release vote

7) Announce via blog, etc.

The point we need to respect is that the "Apache" brand is associated
with open source software that meets the expectations of license
review that Apache promotes.  So if something is broadly made
available, we really should take it through the license review and
voting process, and have a source release, even in small cases like

Of course, this all has overhead, especially for you, the release
manager.  So we don't want to repeat this too frequently.  But
translators continue to come in, and will do so.  It might help if we
Adopt a convention that sets expectations clearly for project
participants and users, maybe something like:

1) When a point release is necessary, for example to fix a critical
bug, we will include any new additional languages since the last
release, provided the translations are complete and will be tested
before the Release Candidate is ready to be voted on.

2) If no point release is necessary, we will include new translations
in the next major release.

3) However, if the next major release is more than X months away then
we will release language packs for new translations that are complete
and tested.

I don't know what the value of X is for #3, but the idea is we
probably don't want to do a lang pack immediately before a new
release. We'd just roll it into the next release.

Just an idea.


> Juergen
>> -Rob
>>> Regards
>>> Ricardo
>>>>> -Rob
>>>>>> -Rob
>>>>>>> Regards,
>>>>>>> Dave

View raw message