On Thu, Aug 25, 2016 at 2:55 PM, 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. >> > Ok, from what I saw in Pootle, it looked like at least were VERY close to be added. >> 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. >> > Great to hear this! I read through some old documentation on the wiki and I didn't know if it still applied or not. > >> 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? > > Possible security issues. I can not imagine at this point in time that ANYONE is really using java 1.5 as a default java installation. I don't think this is a capricious change. Java 1.5 has been out of service updates by anyone for I think at least 4 years. The EOL on it was Oct., 2009. If we continually build with java 1.5, I would think our user base would wonder what "issues" using this old Java might mean for their security. Right now when I uild with java 1.8, and have enhancing messaging for the java component builds, I get a lot of "xxxx is deprecated" messages. Yes, we could fix this. I hope these deprecations are not leading to further problems down the line. Even Java 1.7 is dated and is EOL via Oracle. However, I am still getting updates 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, >> > So far, I haven't seen any. Most of us are building with either Java 1.7, or Java 1.8. The Windows build switched to Java 7 at least 2 years ago if I'm not mistaken. I have NO idea why this was not done with ALL our builds. No additional work except to just use the newer versions. Everything still works near as I can tell. We can not in good conscience continue to supply software built with the old outdated version of Java. > 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. >> > I think we're good. No worries. >> 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 >> > OK. Good point. >> *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. >> > Checked by builders? I've been using ant 1.92 ever since I can remember to build AOO since that what was in the Building Guide. I think the update in configure.ac was just overlooked. > >> *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. >> >> >> >> > > > -- ---------------------------------------------------------------------- MzK "God helps those that help themselves." -- popular adage
