The core team should come up with a list and announce the decision. SOON. Be
firm. Say something like "in xxx months, support for these platforms will be
dropped and we will start to remove that code." Encourage folks interested in
supporting those platforms to maintain a fork. I don't care what you decide
(I'm not likely to be affected) so I won't clutter the list with suggestion
other than "put FIPS on that list." It is holding you back. But whatever.
JUST DECIDE!
Call it version 1.1. Look at the LSB guidelines and nail down the ABI. Make
structures opaque when possible and provide accessor functions. Within openssl
itself use macros if you want. We (Akamai) are willing to help with that if
you'll accept it.
And who is on the core team, anyway? What's the difference between core and dev
team? What's the difference between inactive and emeritus? Fix the
governance; perhaps adopt the Apache model. Why do you need anything other
than "committer" status? How does one progress?
/r$
--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rs...@jabber.me; Twitter: RichSalz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
