/openssl/openssl/labels/hold%3A%20wait%20for%20master
Matthias
> -Original Message-
> From: openssl-project On Behalf Of Matt
> Caswell
> Sent: Thursday, July 9, 2020 11:13 AM
> To: openssl-project@openssl.org
> Subject: Re: Cherry-pick proposal
>
>
>
> On
On 02/06/2020 15:29, Matt Caswell wrote:
>
> There's been no further discussion on this for quite a while, so I will
> start an OTC vote based on the vote text proposed by Matthias and report
> back the results here.
Sorry, I forgot to report back. The final result was:
+1: 4
-1: 4
0: 3
So
On 29/04/2020 14:28, Dr. Matthias St. Pierre wrote:
> - First, a pull request needs to be opened against the master branch for
> discussion.
>
> Only after that pull request has received the necessary amount of
> approvals,
>
> a separate pull request can be opened against the
> OpenSSL_1
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
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
olds - contrary to common practice - even if the change can
> be cherry-picked
> without conflicts from the master branch. The only exception from
> this rule are
> changes which are considered 'CLA: trivial', like e.g.
> typographical fixes.
> >>>>>>
e master branch. The only exception from this rule
are
changes which are considered 'CLA: trivial', like e.g. typographical fixes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Matthias
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
