Re: Beta1 PR deadline

2020-09-10 Thread Dr Paul Dale
Shane has done the IG D.9 work: it is in #12835 and is awaiting review. I think it should be in beta if possible. It’s mostly adding a second test case due to NIST changing guidance recently, so low risk and helpful for the lab. As Shane notes in 12801, there will be some conflicts generated

Re: Beta1 PR deadline

2020-09-10 Thread Matt Caswell
On 10/09/2020 11:40, Matt Caswell wrote: > > > On 09/09/2020 13:03, Kurt Roeckx wrote: >> On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: >>> Please can anyone with PRs that they wish to have included in OpenSSL >>> 3.0 beta1 ensure that they are merged to master by 8th

Re: Beta1 PR deadline

2020-09-10 Thread David von Oheimb
Hi Matt et al., thanks to good collaboration with OTC members I've been able to get approved most of my open PRs that would be good be included before feature freeze, while a few such PRs appear 'nearly' approved. Given the 24-hours grace period, the PRs #12478

Re: Beta1 PR deadline

2020-09-10 Thread David von Oheimb
Hi Matt et al., thanks to good collaboration with OTC members I've been able to get approved most of my open PRs that would be good be included before feature freeze, while a few such PRs appear 'nearly' approved. Given the 24-hours grace period, the PRs #12478

Re: Beta1 PR deadline

2020-09-10 Thread David von Oheimb
On 09.09.20 14:03, Kurt Roeckx wrote: > On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: >> Please can anyone with PRs that they wish to have included in OpenSSL >> 3.0 beta1 ensure that they are merged to master by 8th September. > So that date has passed now. Can someone give an

Re: Reordering new API's that have a libctx, propq

2020-09-10 Thread Michael Richardson
Richard Levitte wrote: > There are many red herrings in here, and I would argue that trying to > be too uniform in the way you think about all functions may be > harmful, because not all functions are classified the same. > We cannot deny that many of our interfaces have an OOP

Re: More GitHub labels

2020-09-10 Thread Dmitry Belyavsky
On Thu, Sep 10, 2020 at 9:20 AM Dr. Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > > ... I think we should change that. This does not mean that a reviewer > who made a change request > > two months ago and lost interest is forced to re-review, only that such > stale reviews must be

RE: More GitHub labels

2020-09-10 Thread Dr. Matthias St. Pierre
> ... I think we should change that. This does not mean that a reviewer who > made a change request > two months ago and lost interest is forced to re-review, only that such stale > reviews must be dismissed > explicitly, if the reviewer does not respond to a re-review request within a >

RE: More GitHub labels

2020-09-10 Thread Dr. Matthias St. Pierre
> Your suggestion seems workable too.  PRs are merged with outstanding change > requests indicated > — a reviewer comments, the comments are addressed then a different reviewer > approves without > the original review being removed.  The labels are a bit more in your face.   > A hybrid “hold:

Re: More GitHub labels

2020-09-10 Thread Dr Paul Dale
Matthias, Your suggestion seems workable too. PRs are merged with outstanding change requests indicated — a reviewer comments, the comments are addressed then a different reviewer approves without the original review being removed. The labels are a bit more in your face. A hybrid “hold:

RE: More GitHub labels

2020-09-10 Thread Dr. Matthias St. Pierre
> Just wondering if we should have two new labels: “hold: tests needed” and  > “hold: documentation needed” labels? > There are a number of PRs that come through where one or both of these are > missing missing. The two use cases you mention are actually better handled by a change request (via