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 prop
* Disabling memory leak checking doesn’t sound like a great idea..
On that one platform, no?
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 Int
* 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
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 addres
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 openssl-project
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 fol
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 long
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 benefit:
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 P
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 303
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 w
12 matches
Mail list logo
