Thought I would mention that the Oracle folks are making noises about helping developers move off of versions of Java < 1.7. They are aware of increasing numbers of vulnerabilities in the older major versions. Of course it isn't our job to nudge users off of XP and older Windows OSes, or get them off of Linux kernel 2.4, but we can get a statistically useful answer about how many of our visitors are using which OS by looking at the web server stats from the different language support sites. Once we see those figures, I rather expect that the flight path will get clearer, relative to support for obsolete OSes and Java versions.
Wolf Halton Mobile/Text 678-687-6104 -- Sent from my iPhone. Creative word completion courtesy of Apple, Inc. > On Aug 25, 2016, at 17:55, Andrea Pescetti <pesce...@apache.org> wrote: > > 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. >> >>> *PRIORITIES* >>> 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. >>> https://bz.apache.org/ooo/show_bug.cgi?id=127068 >> >> 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): >> https://bz.apache.org/ooo/show_bug.cgi?id=126622 >> >>> *BUILDBOTS AND CONFIGURATION* >>> 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. >> >>> *PRODUCTION ENVIRONMENT* ... >>> 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: >>> http://markmail.org/message/b4dbjdeu4llczqwt >> >> 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: l10n-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: l10n-h...@openoffice.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org >
