Back to the topic: If we want to release 4.1.6, we should start the process described here: https://cwiki.apache.org/confluence/display/OOOUSERS/How+to+Cook+a+Release
That said, 4.1.6 should really be the last 4.1.x. (my opinion). We have to get 4.2.0 releasable! Regards, Matthias Am 04.07.2018 um 23:45 schrieb Marcus: > Am 04.07.2018 um 22:46 schrieb Kay Schenk: >> On Wed, Jul 4, 2018 at 1:00 PM, Marcus <marcus.m...@wtnet.de> wrote: >> >>> Am 04.07.2018 um 08:23 schrieb Peter Kovacs: >>> >>>> I think Jim is referring to the gstreamer situation, where we decided >>>> that we skip CentOS6 more or less for 4.2.0.And one argument was, >>>> if they >>>> want something they should support us. This is not showing sympathy >>>> for a >>>> small user group that uses very old software for 2 more years until >>>> they >>>> have to move to CentOS 7. I personally think that the gstreamer >>>> Topic can >>>> be solved after we have released a beta version. Damjan and I have >>>> pointed >>>> out a lot of possible ways to deal with the issue. Just for now I >>>> think we >>>> have other problems then gstreamer in 4.2.0. I think it is my fault >>>> that I >>>> put that argument so much in the front line, but that stuck for me. >>>> >>>> In the last months we had a drop in activity. And more then one topic >>>> received not the attention it deserved. I would not conclude that >>>> anyone >>>> has stopped caring at this point in time. >>>> >>>> >>>> Let us conclude for now: >>>> 4.1.x is still in maintenance. And in my opinion we could think of >>>> maintaining it until 2020 when CentOS6 drops out of maintenance. Some >>>> support from CentOS6 side would be nice. But we need to search >>>> someone for >>>> this. >>>> I have that on my todo list, but did not manage to follow it up. >>>> >>> >>> incl. gstreamer 0.1.0 that is now within the 4.1.x code. >>> >>> PS: >>> CentOS 6 will be supported until Nov 2020; which means another ~2.5 >>> years. >>> >>> 4.2.0 has I think 3 bugs we know about and that blocks a beta release. >>>> Current target for building with gstreamer is CentOS7. Building >>>> without >>>> gstreamer could be done on CentOS6. We should keep the code in >>>> trunc CentOS >>>> 6 compatible where ever we can for now. That will make it easy to >>>> back port >>>> patches to 4.1.x if we decide to maintain 4.1.x until EOL of CentOS6. >>>> >>> >>> In 4.2.0 we can still keep gstreamer 0.1.0 or update to something >>> newer. >>> To be honest, I don't care *about this special topic*. >>> >>> And it is only relevant on Linux, right? >>> >>> IMHO more relevant is the baseline: When we increase the CentOS >>> version we >>> also raise the sysreq for Linux kernel, glibc, etc. This has a much >>> bigger >>> impact for our users. >> >> You are absolutely correct about this, Marcus. Monitoring the 32-bit >> Linux >> downloads might help here. It does seem like AOO could be moving away >> from >> 32-bit for Linux and other operating systems. I don't know what >> impact this >> will have overall though. > > I don't remember exactly, does the gstreamer 0.1.0 vs. 1.0.0 > discussion is also connected to the Linux 32-bit builds? If so, a > solution could be indeed to drop the 32-bit builds. From SF.net stats > I get the following (2018-01-01 until today). > > BTW: > Very likely it's the used OS the download is started from. And not the > OS where OpenOffice should be installed on. > > OS % > ----------------------- > Windows 86,1165 > Macintosh 7,8424 > Unknown 4,9012 > Linux 1,0621 > Android 0,0762 > BSD 0,0011 > Solaris 0,0006 > > But even then, I'm sure the most downloads from resp. for Linux will > be for 64-bit. > > Has anybody more exact numbers - or an idea how to get them? > > Marcus > > > >>> On 03.07.2018 23:50, Matthias Seidel wrote: >>>> >>>>> What impact has Ant 1.10.x exactly on older machines? >>>>> It is no problem for me to build the Windows version with Ant >>>>> 1.9.12. As >>>>> long as we use Java 8. >>>>> >>>>> But again, I just did a personal build to test AOO 4.1.x with Java 8. >>>>> Nothing else. >>>>> To be more precise: I was the only one who cared. No response from >>>>> other >>>>> members! >>>>> >>>>> >>>>> Am 03.07.2018 um 23:19 schrieb Jim Jagielski: >>>>> >>>>>> The above made it appear that Ant 1.9.x was no longer supported plus >>>>>> had some sort of security related issue making it unsuited for >>>>>> AOO... ie, >>>>>> we *needed* to use Ant 1.10 not just that we now *can* use it. >>>>>> >>>>>> How about showing some sympathy and understanding for those who >>>>>> may be >>>>>> stuck w/ older machines? After all, let's be real, our continued >>>>>> support >>>>>> for "older" systems is the only real thing we have going for >>>>>> us... It's >>>>>> these little things that make significant ripples in our >>>>>> eco-system and we >>>>>> seem to not really care about that anymore. >>>>>> >>>>>> On Jul 3, 2018, at 4:02 PM, Matthias Seidel >>>>>> <matthias.sei...@hamburg.de> >>>>>>> wrote: >>>>>>> >>>>>>> Am 03.07.2018 um 21:45 schrieb Jim Jagielski: >>>>>>> >>>>>>>> On Jul 1, 2018, at 11:27 AM, Peter Kovacs <pe...@apache.org> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi everbody. >>>>>>>>> >>>>>>>>> >>>>>>>>> I would like to bring a 4.1.6 Release on the way in July. Even >>>>>>>>> if we >>>>>>>>> manage to get 4.2.0 ready it will only be a beta. And we have >>>>>>>>> some stuff to >>>>>>>>> get out to the people. >>>>>>>>> >>>>>>>>> Matthias has created a suggestion for a 4.1.6 release on >>>>>>>>> security. >>>>>>>>> Containing some security fixes, plus >>>>>>>>> >>>>>>>>> >>>>>>>>> - Java 8 Update 172 >>>>>>>>> - Apache Ant 1.10.3 >>>>>>>>> >>>>>>>> What is wrong w/ Apache Ant 1.9.12? Why the need for 1.10.x? >>>>>>>> >>>>>>> What is wrong with Ant 1.10.x? If we build with Java 8 we can use >>>>>>> it... ;-) >>>>>>> My test build was just a Proof-of-Concept what can be done with AOO >>>>>>> 4.1.x. >>>>>>> >>>>>>> But of course we can build with 1.9.x if that is wanted? >>>>>>> >>>>>>> Regards, >>>>>>> Matthias > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
smime.p7s
Description: S/MIME Cryptographic Signature
