Re: Cherry-pick proposal

2020-04-29 Thread Tim Hudson
Any change to the review gate check we have in place now that lowers it will certainly not get my support. If anything, that check before code gets approved should be raised, not lowered. Tim. On Thu, 30 Apr 2020, 1:24 am Salz, Rich, wrote: > I suspect that the primary motivation for this

Re: CI build timeouts

2020-04-29 Thread Salz, Rich
* Disabling memory leak checking doesn’t sound like a great idea.. On that one platform, no?

Re: Revisiting tradition: branches and tags

2020-04-29 Thread Short, Todd
As someone who is currently playing around with QUIC branches based on the tags and branch names, I *always* screw things up while typing. I wouldn't mind if the key were banned from tags and branch names. -- -Todd Short // tsh...@akamai.com // “One if by land, two if by sea, three if by the

Re: Cherry-pick proposal

2020-04-29 Thread Salz, Rich
I suspect that the primary motivation for this proposal is that PR’s against master often become stale because nobody on the project looks at them. And then submitters are told to rebase, fix conflicts, etc. It gets disheartening. If that is the motivation, then perhaps the project should

Re: OpenSSL version 3.0.0-alpha1 published

2020-04-29 Thread Sergio NNX
* Windows 10 x64 * GCC 8.3.0 x86_64 $ openssl version -a OpenSSL 3.0.0-alpha1 "23 Apr 2020" (Library: OpenSSL 3.0.0-alpha1 "23 Apr 2020") built on: Fri Apr 24 18:14:53 2020 UTC platform: mingw64 options: bn(64,64) compiler: /mingw/bin/gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501

Re: Cherry-pick proposal

2020-04-29 Thread Tomas Mraz
That we do not run CI explicitly before such cherry picks does not mean that there is no CI run at all. The CI is triggered when the cherry- picked commit is merged. If we were checking the status of the 1.1.1 branch CI runs periodically (with a bot sending e-mails about failures to

RE: Cherry-pick proposal

2020-04-29 Thread Dr. Matthias St. Pierre
I completely agree with Nicolas reasoning. But we should try to keep things simple and not add too many regulations. What do you think of the following formulation? > For change requests which target both the master and the OpenSSL_1_1_1-stable branch, the

Re: Cherry-pick proposal

2020-04-29 Thread Richard Levitte
I find the idea of *mandatory* separate PRs for master and 1.1.1 awful. There's still a lot of code that hasn't changed at all. CMS, BIO, ... We already have the policy that if we get a clean cherry-pick, we go with it, otherwise we make a separate PR. I've followed that guiding rule for a

Re: Cherry-pick proposal

2020-04-29 Thread Nicola Tuveri
I think we changed enough things in the test infrastructure that there is a chance of creating subtle failures by merging cherry-picked commits from master directly. >From the burden perspective, from my point of view having a separate PR that ran all the CI without failures is actually a

Re: Cherry-pick proposal

2020-04-29 Thread Nicola Tuveri
I can agree it is a good idea to always require backport as a separate PR, with the following conditions: - unless it's a 1.1.1 only issue, we MUST always wait to open the backport-to-111 PR until after the master PR has been approved and merged (to avoid splitting the discussions among different

Re: Cherry-pick proposal

2020-04-29 Thread Dr Paul Dale
My concern is are 1.1.1 and 3.0 really all that different? The core is quite different but the cryptographic algorithms aren’t. CMS, x509, …? I’d rather not introduce a burden where it isn’t necessary. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7

Cherry-pick proposal

2020-04-29 Thread Matt Caswell
The OTC have received this proposal and a request that we vote on it: I would like to request that we do not allow cherry-picks between master and 1.1.1-stable because these two versions are now very different, if a cherry-pick succeeds, there is no guarantee that the result will work. Because