On 5 July 2014 18:46, Zoltan Arpadffy <z...@polarhome.com> wrote: > Hi, > > I absolutely agree, that other less popular platforms need support. > > Unfortunately, reading the conversation in the last few days, I got a > feeling that the OpenSSL core development is not willing to support those > platforms in the main line, but will come up with a separate branch or other > merging strategy keeping the core code clean.
I don't think that's the plan at all - but if no-one cares enough about them to make sure we can actually test and fix them on those platforms, _then_ we'll almost certainly drop support. I am not promising that we'll support any random platform that we can test and fix on, but that's surely a minimum requirement. And if someone out there is prepared to do the fixing for us, even better. > Whatever this solution will be - I silently accept this decision - moreover > understand the reasoning behind too. > ...but can not let the less popular platforms decline, therefore I decided > to set up Jenkins builds on polarhome.com's 30+ rare operating systems and > run daily builds and tests feeding the core team with propper test data and > eventually bugs from those environments right after a change occured in the > main code. > > This CI approach will improve the code quality generaly and reduce the gap > between the less supported platforms code and the main code. +1. > > polarhome has AIX, HP-UX, OpenVMS, QNX Ultrix, IRIX and many other platforms > and architectures that would be of interest. > > The service will be soon publicly available. > > Regards, > Z > > > > Quoting hmbrand via RT <r...@openssl.org>: > >> In the new roadmap I read on platform strategy: >> --8<--- >> Platform Strategy >> >> Moving forward OpenSSL will adopt the following policy: >> >> • There will be a defined set of primary platforms. The primary >> platforms will be Linux and FreeBSD. A primary platform is one where >> most development occurs. >> >> • In addition there will be a list of secondary platforms which are >> supported by the development team. >> >> • Platform specific code will be moved out of the main codebase >> (removing overuse of "ifdef"). >> >> • Legacy platforms that are unlikely to have wide deployment will be >> removed from the code. >> >> • Non-supported platforms requiring regular maintenance activities will >> eventually be removed from the code after first seeking community owners >> to support the platforms in platform specific repositories. >> >> Necessary criteria for a platform to be included in the secondary >> platform list includes: >> >> • Currency, i.e. a platform is widely deployed and in current use >> >> • Vendor support >> >> • Available to the dev team, i.e. the dev team have access to a suitable >> environment in which to test builds and deal with tickets and issues >> >> • Dev team ownership, i.e. at least one person on the team is willing to >> take some responsibility for a platform >> >> In addition the secondary list will be as small as possible so as not to >> spread the development team too thinly. >> >> The secondary platforms are still to be defined but will be based on the >> above criteria. For each primary/secondary platform, we should have, at >> least, a continuous integration box and a dev machine we can access for >> test/debug. We will seek support from the platform vendors or the >> community to provide access to these platforms. The secondary platform >> list will change over time, but an initial list will be produced within >> three months. >> >> The Platform Strategy will be phased in over a period of time based on >> how quickly we can refactor the code. >> -->8--- >> >> I think it is highly thinkable that the dev-team does not have access to >> proprietary OS's like HP-UX or AIX. Personally I give a shit about AIX, >> but I value HP-UX a lot and I might be the only one left still releasing >> software-depots (what HP uses for binary distributions) for a lot of >> OpenSource products for HP-UX back to 10.20, long dead and gone >> according to HP itself. >> >> Looking at the download-statistics, it is still used quite a lot >> worldwide. Who am I to judge that. I just have access to development >> boxes for HP-UX 10.20, 11.00, 11.11 (11iv1), 11.23 (11iv2 PA2), 11.23 >> (11iv2 ia64) and 11.31 (11iv3 ia64 and as I have a warm heart for >> OpenSourse, with perl5 especially, I will try to continue to release >> modern recent packages of heavily used OpenSource software for thes >> OS's. OpenSSL is one of those (you can check that on >> http://mirrors.develooper.com/hpux/ ) >> >> If you remove native code to support the OS versions the developers have >> no access to or do not care about, you will make it harder for the >> volunteers like me to post OpenSSL to those systems. We do this in our >> free time, as the "big" vendors do not support the OS releases they have >> declared end-of-life. >> >> This ticket is a plea to keep the code related to HP-UX in place or at >> least easily available: That might include *not* using libtool, as that >> was once created to make linking on other systems than Linux easier, but >> it only complicated things for those OSs and sometimes causes 100% fail >> (AIX). >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> Development Mailing List openssl-dev@openssl.org >> Automated List Manager majord...@openssl.org >> > > > > --- > WebMail, polarhome.com > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
