openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <>
Subject Re: [DISCUSS] Release 4.2: General Topics
Date Thu, 25 Aug 2016 21:55:28 GMT
Resending to 3 lists... I suggest to have a "canonical" reply-to to the 
dev list for the next messages. Andrea

Andrea Pescetti wrote:
> On 23/08/2016 Kay Schenk wrote:
>> WARNING: This is quite long!
> And the discussion was even longer, but I'll start with answering this one.
> And I'll first note that:
> 1) Work is not starting now. We have years of code already committed and
> not shown in previous releases.
> 2) Like for every release, we make plans but at a certain point we have
> to cut the release and this "wishlist" is thus a tentative guideline.
>> 1. Update the localization.
>> We've had quite a bit of work by the localization folks since the 4.1.1
>> release. This was the last release, in 2014-08-21 to import localization
>> updates. Currently, it seems we might also add 3 new languages: Uyghur,
>> Sinhala, and Icelandic with the 4.2 release. This would include both UI
>> translations and Help translations.
> Last translations import were done in 4.1.0 and not 4.1.1 (if I recall
> correctly); but this is a minor detail. There are no new languages to be
> expected in 4.2.0: we have new languages in Pootle, but I don't think
> any of them is ready enough for being released (this may of course
> improve with time). So in short 4.2.0 means that we can add strings to
> the code, which means we can make them available to translators, which
> in turn means we can (we have to) update all translations.
>> We need volunteers to lead this endeavor. I, personally, don't know
>> anything about this process.
> I'm slowly working on this but I still have something to find/learn.
> I've sent the l10n list a mail sending that I'm planning to test a first
> import in early September - just to test the process.
>> 2. Update Java requirement from Java 1.5 to *at least* Java 1.7
>> I am rather adamant that we change our building requirement to Java 1.7
>> for all platforms. I will be changing that in our Building Guide today.
> Is there a real reason for it? I see this like saying (this is just an
> example, not to be taken literally) "we drop support for Windows XP
> since it's old and unsupported". In short: if we need work to drop Java
> 1.5 then we have clear advantages in raising our requirement to 1.7,
> otherwise we can simply drop the requirement saying "we won't explicitly
> test compatibility with Java < 1.7"; but in that case we must provide
> ways to obtain a compatible JRE for all the 4 supported platforms.
>> 3. Issues for inclusion
>> We need to include submitted/tested patches since 4.0.x. This should not
>> include UI changes which would need to undergo a much longer test period.
> The version number is not a detail. We call it 4.2.0 since UI changes
> are allowed. On the other hand, we don't have to include all patches;
> actually, seeing all the code that already went in, I would be more on
> the conservative side here.
>> Additionally, issue 127068, involving analytics on our source code would
>> surely be worth investigating.
> These are automatically found defects, good for easy fixes but probably
> not really important.
> I'd rather suggest that we give some attention to the 4.1.2 regressions,
> especially this one (the only one so far):
>> 1. Move to different buildbots?
> Not needed. A "nice to have" if they standardize it, but buildbots (I
> mean, the Linux version they use) are not so relevant for a release.
>> 2. Configuration Issues
>> Add, at least the ant version we're checking for in our configuration is
>> not the version recommended in our Building Guide.
> The this is a bug in configure, needs its own issue and must be checked.
>> It has
>> been suggested that we use the ASF buildbots to produce our binaries
>> with this release.
> The ASF buildbots and releases cover two different fields. I've been
> misunderstood from time to time, but just to make it clear: I would
> never want that we use the buildbots for releasing (at least for Linux),
> since you want a recent Linux on buildbots and on old Linux on the
> release VM (where this VM is hosted can be deferred to a separate thread).
>> Andrea has volunteered to set up a production environment for us. SEE:
> I see that discussion has been misunderstood. I'll reply there. It
> suffices to say, here, that I'm not suggesting to use buildbots for the
> release builds. Which basically means I agree with your point of view in
> this respect.
> Regards,
>    Andrea.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message