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
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
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.
// “One if by land, two if by sea, three if by the
* Disabling memory leak checking doesn’t sound like a great idea..
On that one platform, no?
* 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
compiler: /mingw/bin/gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501
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,
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
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
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
On Thu, 30 Apr 2020, 1:24 am Salz, Rich, wrote:
> I suspect that the primary motivation for this
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
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
>From the burden perspective, from my point of view having a separate PR
that ran all the CI without failures is actually a
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.
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,
I’d rather not introduce a burden where it isn’t necessary.
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7
Mail list logo