[openssl.org #3436] Platform strategy

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #3436] Platform strategy

Rich Salz via RT
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3436] Platform strategy

Zoltan Arpadffy
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.

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.

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 <[hidden email]>:

> 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                       [hidden email]
> Automated List Manager                           [hidden email]
>



---
WebMail, polarhome.com
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3436] Platform strategy

Ben Laurie-2
On 5 July 2014 18:46, Zoltan Arpadffy <[hidden email]> 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 <[hidden email]>:
>
>> 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                       [hidden email]
>> Automated List Manager                           [hidden email]
>>
>
>
>
> ---
> WebMail, polarhome.com
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [hidden email]
> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3436] Platform strategy

Tim Hudson
In reply to this post by Rich Salz via RT
On 5/07/2014 1:06 PM, hmbrand via RT wrote:
> 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.

Are you able to provide ssh access into those systems for OpenSSL
development team vendors?

Tim.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #3436] Platform strategy

Salz, Rich
In reply to this post by Zoltan Arpadffy
> ...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

Wow, that is really great.  Thank you!

As Ben said, we haven't decided on *anything* yet.

        /r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [hidden email]; Twitter: RichSalz

:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #3436] Platform strategy

Zoltan Arpadffy
You are most welcome.
This is the main purpose of polarhome.

I have been working few days with that setup and I see already that it  
will not be as smooth as somebody would guess, because java, git etc  
are not available, or supported on every system.

I have sent a preview to Tim, but when the builds will be established  
I'll make the link publicly available.

Regards,
Z


Quoting "Salz, Rich" <[hidden email]>:

>> ...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
>
> Wow, that is really great.  Thank you!
>
> As Ben said, we haven't decided on *anything* yet.
>
> /r$
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge, MA
> IM: [hidden email]; Twitter: RichSalz
>
> :��I"Ϯ��r�m���� (����Z+�7�zZ)���1���x ��h����W^��^��%����&jם.+-1�ځ��j:+v�������h�



---
WebMail, polarhome.com
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]