Please consider delaying the Beta-1 freeze for a week or two

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

Please consider delaying the Beta-1 freeze for a week or two

Jeffrey Walton-3
Hi Everyone,

Testing master on real hardware is showing some minor issues on a few
platforms, including ARM32, ARM64, PowerPC and i686. In addition,
there seems to be one-off issues on other combinations, like VIA's C7
processor on Linux.

In addition to the base issues, there are other minor issues like
failing to configure and compile with 'no-comp'. Other configuration
dependent issues include failed self tests under PowerPC in a shared
configuration.

Please consider delaying the freeze for a week or two while the issues
are being ironed out.

Jeff
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Richard Levitte - VMS Whacker-2
In message <CAH8yC8km0L5GN7igytwkj=[hidden email]> on Thu, 10 Mar 2016 20:03:11 -0500, Jeffrey Walton <[hidden email]> said:

noloader> Hi Everyone,
noloader>
noloader> Testing master on real hardware is showing some minor issues on a few
noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
noloader> there seems to be one-off issues on other combinations, like VIA's C7
noloader> processor on Linux.
noloader>
noloader> In addition to the base issues, there are other minor issues like
noloader> failing to configure and compile with 'no-comp'. Other configuration
noloader> dependent issues include failed self tests under PowerPC in a shared
noloader> configuration.
noloader>
noloader> Please consider delaying the freeze for a week or two while the issues
noloader> are being ironed out.

The upcoming release is the first beta of two planned, and we've
already delayed the first for a few extra days.  It is not a final
release, so there's still time to fix things like these.

Please see the bottom of the release strategy for the planned dates:

http://openssl.org/policies/releasestrat.html

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Matt Caswell-2
In reply to this post by Jeffrey Walton-3


On 11/03/16 01:03, Jeffrey Walton wrote:

> Hi Everyone,
>
> Testing master on real hardware is showing some minor issues on a few
> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
> there seems to be one-off issues on other combinations, like VIA's C7
> processor on Linux.
>
> In addition to the base issues, there are other minor issues like
> failing to configure and compile with 'no-comp'. Other configuration
> dependent issues include failed self tests under PowerPC in a shared
> configuration.
>
> Please consider delaying the freeze for a week or two while the issues
> are being ironed out.

I'd argue that a freeze helps us to iron the issues out. Problems tend
to get introduced when new features are added. By declaring a freeze we
no longer accept new features and can instead divert our attention to
stability and bug fixing.

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Jeffrey Walton-3
In reply to this post by Richard Levitte - VMS Whacker-2
> noloader> Testing master on real hardware is showing some minor issues on a few
> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
> noloader> there seems to be one-off issues on other combinations, like VIA's C7
> noloader> processor on Linux.
> noloader>
> noloader> In addition to the base issues, there are other minor issues like
> noloader> failing to configure and compile with 'no-comp'. Other configuration
> noloader> dependent issues include failed self tests under PowerPC in a shared
> noloader> configuration.
> noloader>
> noloader> Please consider delaying the freeze for a week or two while the issues
> noloader> are being ironed out.
>
> The upcoming release is the first beta of two planned, and we've
> already delayed the first for a few extra days.  It is not a final
> release, so there's still time to fix things like these.
>
> Please see the bottom of the release strategy for the planned dates:
>
> http://openssl.org/policies/releasestrat.html

Well, would it be possible to survey supported platforms and see if it
makes sense to move forward at this point? Does the library maintain a
matrix of test platforms and results?

Releasing a Beta-1 seems like its missing the point if the the point
of the beta is to test it. There are issues in {configure|build|test}
on ARM32, ARM64, OpenBSD, Windows and some Linux i686 and x86_64
targets/configurations. I'm also wondering about MIPS, NetBSD, FreeBSD
and Gentoo.

Maybe something else to ponder in the big picture of release
engineering... Why are the breaks occurring and not being caught? Why
is the engineering process not catching them?

(I think its OK to break things on occasion. You can't make an omelet
without breaking eggs. But the idea is you have to catch them quickly
and early before the user experiences the pain point. If the break is
fixed before the user experiences the pain, then it "no blood, no
foul" in my book).

There's no need to rush the process. OpenSSL does not answer to anyone
except its own quality standards. It seems like stepping back, coming
up for some air, catching your breath and then diving back in will
produce better results in the end.

Jeff
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Ben Laurie-2
On 11 March 2016 at 09:24, Jeffrey Walton <[hidden email]> wrote:

>> noloader> Testing master on real hardware is showing some minor issues on a few
>> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
>> noloader> there seems to be one-off issues on other combinations, like VIA's C7
>> noloader> processor on Linux.
>> noloader>
>> noloader> In addition to the base issues, there are other minor issues like
>> noloader> failing to configure and compile with 'no-comp'. Other configuration
>> noloader> dependent issues include failed self tests under PowerPC in a shared
>> noloader> configuration.
>> noloader>
>> noloader> Please consider delaying the freeze for a week or two while the issues
>> noloader> are being ironed out.
>>
>> The upcoming release is the first beta of two planned, and we've
>> already delayed the first for a few extra days.  It is not a final
>> release, so there's still time to fix things like these.
>>
>> Please see the bottom of the release strategy for the planned dates:
>>
>> http://openssl.org/policies/releasestrat.html
>
> Well, would it be possible to survey supported platforms and see if it
> makes sense to move forward at this point? Does the library maintain a
> matrix of test platforms and results?
>
> Releasing a Beta-1 seems like its missing the point if the the point
> of the beta is to test it. There are issues in {configure|build|test}
> on ARM32, ARM64, OpenBSD, Windows and some Linux i686 and x86_64
> targets/configurations. I'm also wondering about MIPS, NetBSD, FreeBSD
> and Gentoo.

FreeBSD hangs in the networking tests (70-*) currently.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Jaroslav Imrich
In reply to this post by Matt Caswell-2
On 11 March 2016 at 10:21, Matt Caswell <[hidden email]> wrote:
I'd argue that a freeze helps us to iron the issues out. Problems tend
to get introduced when new features are added. By declaring a freeze we
no longer accept new features and can instead divert our attention to
stability and bug fixing.

I would like to point out that there are several already reviewed pull requests with new features - e.g. [0] and [1] - waiting to be merged. Do openssl devs plan to address these before 1.1 freeze?

[0] https://github.com/openssl/openssl/pull/576
[1] https://github.com/openssl/openssl/pull/771

Regards, Jaroslav

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Salz, Rich
> I would like to point out that there are several already reviewed pull requests with new features - e.g. [0] and [1] - waiting to be merged. Do openssl devs plan to address these before 1.1 freeze?

>[0] https://github.com/openssl/openssl/pull/576
> [1] https://github.com/openssl/openssl/pull/771

Some yes, and some no.  In these particular cases 576 is a bugfix and can make it after.  771, sadly, seems unlikely.  Both of these have commentary in the text that indicates their status.  We've tried to be upfront about the state of everything.  Sometimes responses get delayed.  If there are any PR's that you (or anyone) are particularly interested in, please post a comment there.

Freeze is in a few hours.  Anything that is not already in progress (dual review going on, for example) will probably not make it, unless it's a bugfix.
 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Jaroslav Imrich

On 11 March 2016 at 15:22, Salz, Rich <[hidden email]> wrote:
> I would like to point out that there are several already reviewed pull requests with new features - e.g. [0] and [1] - waiting to be merged. Do openssl devs plan to address these before 1.1 freeze?

>[0] https://github.com/openssl/openssl/pull/576
> [1] https://github.com/openssl/openssl/pull/771

Some yes, and some no.  In these particular cases 576 is a bugfix and can make it after.  771, sadly, seems unlikely.  Both of these have commentary in the text that indicates their status.  We've tried to be upfront about the state of everything.  Sometimes responses get delayed.  If there are any PR's that you (or anyone) are particularly interested in, please post a comment there.

Freeze is in a few hours.  Anything that is not already in progress (dual review going on, for example) will probably not make it, unless it's a bugfix.

Rich, you are my personal hero for all the work you do on OpenSSL (active in discussions, a lot of PR reviews, RT cleanup ...) but from my point of view it is really hard to contribute code to OpenSSL.

I have already mentioned in comments [2][3] that I am particularly interested in getting PR#576 and PR#771 into 1.1 but IMO it is too hard to attract the attention of the rest of core devs - reviewed PR is waiting on GitHub, bug is opened in RT, message was posted to openssl-dev mailinglist. I feel really sorry for the authors of PR's that got first review but their code won't get into 1.1 because of missing second review. I know their pain since I've been waiting 5 years for the inclusion of my last patch [4] but let's hope it will get better for 1.2 :)


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Salz, Rich
> but from my point of view it is really hard to contribute code to OpenSSL.

Things are much better, but it is still harder than we'd like.  Hopefully it will continue to improve.

> I feel really sorry for the authors of PR's that got first review but their code won't get into 1.1 because of missing second review.

Yes, it's a particularly bad kind of limbo to be stuck in.

Again, thanks for sticking with us, and keep pushing to get better.

        /r$
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Erik Forsberg-11
In reply to this post by Jeffrey Walton-3
add Solaris to the platforms that are not at beta-level yet.
Richard Levitte and myself are helping each other out though, so we should be close

>-- Original Message --
>
>> noloader> Testing master on real hardware is showing some minor issues on a few
>> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
>> noloader> there seems to be one-off issues on other combinations, like VIA's C7
>> noloader> processor on Linux.
>> noloader>
>> noloader> In addition to the base issues, there are other minor issues like
>> noloader> failing to configure and compile with 'no-comp'. Other configuration
>> noloader> dependent issues include failed self tests under PowerPC in a shared
>> noloader> configuration.
>> noloader>
>> noloader> Please consider delaying the freeze for a week or two while the issues
>> noloader> are being ironed out.
>>
>> The upcoming release is the first beta of two planned, and we've
>> already delayed the first for a few extra days.  It is not a final
>> release, so there's still time to fix things like these.
>>
>> Please see the bottom of the release strategy for the planned dates:
>>
>> http://openssl.org/policies/releasestrat.html
>
>Well, would it be possible to survey supported platforms and see if it
>makes sense to move forward at this point? Does the library maintain a
>matrix of test platforms and results?
>
>Releasing a Beta-1 seems like its missing the point if the the point
>of the beta is to test it. There are issues in {configure|build|test}
>on ARM32, ARM64, OpenBSD, Windows and some Linux i686 and x86_64
>targets/configurations. I'm also wondering about MIPS, NetBSD, FreeBSD
>and Gentoo.
>
>Maybe something else to ponder in the big picture of release
>engineering... Why are the breaks occurring and not being caught? Why
>is the engineering process not catching them?
>
>(I think its OK to break things on occasion. You can't make an omelet
>without breaking eggs. But the idea is you have to catch them quickly
>and early before the user experiences the pain point. If the break is
>fixed before the user experiences the pain, then it "no blood, no
>foul" in my book).
>
>There's no need to rush the process. OpenSSL does not answer to anyone
>except its own quality standards. It seems like stepping back, coming
>up for some air, catching your breath and then diving back in will
>produce better results in the end.
>
>Jeff
>--
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Please consider delaying the Beta-1 freeze for a week or two

Emilia Käsper-2
Returning to the issue at hand:

On Fri, Mar 11, 2016 at 7:24 PM Erik Forsberg <[hidden email]> wrote:
add Solaris to the platforms that are not at beta-level yet.
Richard Levitte and myself are helping each other out though, so we should be close

>-- Original Message --
>
>> noloader> Testing master on real hardware is showing some minor issues on a few
>> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
>> noloader> there seems to be one-off issues on other combinations, like VIA's C7
>> noloader> processor on Linux.
>> noloader>
>> noloader> In addition to the base issues, there are other minor issues like
>> noloader> failing to configure and compile with 'no-comp'. Other configuration
>> noloader> dependent issues include failed self tests under PowerPC in a shared
>> noloader> configuration.
>> noloader>
>> noloader> Please consider delaying the freeze for a week or two while the issues
>> noloader> are being ironed out.
>>
>> The upcoming release is the first beta of two planned, and we've
>> already delayed the first for a few extra days.  It is not a final
>> release, so there's still time to fix things like these.
>>
>> Please see the bottom of the release strategy for the planned dates:
>>
>> http://openssl.org/policies/releasestrat.html
>
>Well, would it be possible to survey supported platforms and see if it
>makes sense to move forward at this point? Does the library maintain a
>matrix of test platforms and results?
>
>Releasing a Beta-1 seems like its missing the point if the the point
>of the beta is to test it. There are issues in {configure|build|test}
>on ARM32, ARM64, OpenBSD, Windows and some Linux i686 and x86_64
>targets/configurations. I'm also wondering about MIPS, NetBSD, FreeBSD
>and Gentoo.
>
>Maybe something else to ponder in the big picture of release
>engineering... Why are the breaks occurring and not being caught? Why
>is the engineering process not catching them?
>
>(I think its OK to break things on occasion. You can't make an omelet
>without breaking eggs. But the idea is you have to catch them quickly
>and early before the user experiences the pain point. If the break is
>fixed before the user experiences the pain, then it "no blood, no
>foul" in my book).
>
>There's no need to rush the process. OpenSSL does not answer to anyone
>except its own quality standards. It seems like stepping back, coming
>up for some air, catching your breath and then diving back in will
>produce better results in the end.
>
>Jeff
>--
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev