Re: New GitHub label for release blockers

2020-09-13 Thread Nicola Tuveri
s for the official documentation you > mentioned, are you talking about this one? > https://github.com/features/project-management > > Matthias > > > From: Nicola Tuveri > Sent: Sunday, September 13, 2020 4:17 PM > To: Dr. Matthias St. Pierre > Cc: openssl-project@openssl

Re: New GitHub label for release blockers

2020-09-13 Thread Nicola Tuveri
Matthias overcredits me: I just wanted to know his opinion about when we should use labels and when milestones (and that is why I wrote to him off-list, as a very confused and shy pupil asking a sensei for wisdom pearls). All the alleged convincing was self-inflicted :P And now that my

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

2020-09-05 Thread Nicola Tuveri
On Sat, Sep 5, 2020, 14:01 Tim Hudson wrote: > On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri wrote: > >> Or is your point that we are writing in C, all the arguments are >> positional, none is ever really optional, there is no difference between >> passing a `(void*)

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

2020-09-05 Thread Nicola Tuveri
On Sat, Sep 5, 2020, 12:13 Tim Hudson wrote: > On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote: > >> In most (if not all) cases in our functions, both libctx and propquery >> are optional arguments, as we have global defaults for them based on the >

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

2020-09-05 Thread Nicola Tuveri
Thanks Tim for the writeup! I tend to agree with Tim's conclusions in general, but I fear the analysis here is missing an important premise that could influence the outcome of our decision. In most (if not all) cases in our functions, both libctx and propquery are optional arguments, as we have

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Nicola Tuveri
Sorry yes, I meant to refer to the open PR with the s390 support, I picked the wrong number! On Thu, Jun 25, 2020, 17:54 Matt Caswell wrote: > > > On 25/06/2020 15:33, Nicola Tuveri wrote: > > In light of how the discussion evolved I would say that not only there > > is co

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Nicola Tuveri
In light of how the discussion evolved I would say that not only there is consensus on supporting the definition of a detailed policy on backports and the definitions of what are the requirements for regular releases vs LTS releases (other than the longer support timeframe), but also highlights a

Re: The hold on PR 12089

2020-06-10 Thread Nicola Tuveri
I believe the OMC is called into action as some name changes might be seen as breaking API or ABI compatibility and that has been considered so far as part of the first item in the OMC prerogatives list. The matter of OMC Vs OTC vote also depends on what kind of hold Tim is applying with his - 1:

Re: addrev warning

2020-06-08 Thread Nicola Tuveri
Yes, I also got that since I updated my git installation from the upstream source tarball. With recent versions of git this warning has been showing for months already, but I don't know enough about it to propose a fix! Nicola On Mon, Jun 8, 2020, 12:16 Matt Caswell wrote: > After upgrading

Re: Some more extra tests

2020-05-07 Thread Nicola Tuveri
I would be interested in seeing a PR to see what enabling these tests would require! I believe we do indeed need to test more thoroughly to ensure we are not breaking the engine API! Nicola On Thu, May 7, 2020, 21:08 Dmitry Belyavsky wrote: > Dear colleagues, > > Let me draw your attention

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: Face to face

2020-03-04 Thread Nicola Tuveri
I would like to propose as a date for the OTC meeting somewhere close to the projected release date for 3.0alpha1. Ideally it would be nice if OMC and OTC could coordinate the dates to be close enough to ease the discussion of agenda items that might require coordination between OMC and OTC. My

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
On Fri, 14 Feb 2020 at 14:00, Matt Caswell wrote: > > To be clear the build that is timing out uses *msan* not *asan*. > As I understand it msan detects unitialised reads. whereas asan detects > memory corruption, buffer overflows, use-after-free bugs, and memory leaks. > > The previous

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
If ASAN is too slow to run in the CI should we restore the previous homemade checks for memory leaks as an alternative to be run in regular CI runs and leave ASAN builds to run-checker on the master branch only? Here is another idea that would be interesting if we restore the previous checks: I

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Nicola Tuveri
I have always implicitly assumed Matt view, but I am happy to conform to what the consensus is. I believe this discussion is very useful and could contribute a new entry in the commiter guidelines. Nicola On Fri, May 24, 2019, 07:21 Matt Caswell wrote: > > > On 24/05/2019 15:10, Richard