Re: 3.0 beta 1 milestone
On Thu, 17 Sep 2020 15:57:52 +0200, Tomas Mraz wrote: > I do not think the milestone should include nice-to-have items. Another view is that beta 1 is feature freeze. If those nice to have items are characterized as new features, then it makes sense to have them included in the beta 1 milestone if we want them for 3.0.0. Otherwise, we will have to put them on the waiting list for after 3.0.0. If they are not characterized as new features, that is a different matter, of course. The conclusion is that we will have to take some time (I assume that'll be quick in most cases) thinking how we characterize certain PRs before beta 1 is released. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: 3.0 beta 1 milestone
On Thu, 17 Sep 2020 18:49:19 +0200, Kurt Roeckx wrote: > > On Thu, Sep 17, 2020 at 01:48:18PM +0100, Matt Caswell wrote: > > So - this leads me to the question - what is the milestone for? Does it > > means these things *must* go in before we can release beta 1? Or does it > > mean we would *like* to get these things in for beta 1? > > We need to have a decision about those before beta 1, which can > include: > - It should be in beta 1 > - It doesn't block beta 1, before the 3.0 release is fine too, > which just means that you change the milestone to 3.0 > - It doesn't go into 3.0. No idea what the best way to tag them > is. Sorry, I realise I repeated what you said... Regarding things not going into 3.0.0, one way is not to assign a milestone to them. If we decide to do it that way, it probably means that we should set the 3.0.0 milestone on everything that we consider a bug fix rather than a new feature. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: 3.0 beta 1 milestone
On Fri, 2020-09-18 at 09:26 +0200, Richard Levitte wrote: > On Thu, 17 Sep 2020 15:57:52 +0200, > Tomas Mraz wrote: > > I do not think the milestone should include nice-to-have items. > > Another view is that beta 1 is feature freeze. If those nice to have > items are characterized as new features, then it makes sense to have > them included in the beta 1 milestone if we want them for 3.0.0. > Otherwise, we will have to put them on the waiting list for after > 3.0.0. Yes, but that effectively makes them either "must have in beta1" if we decide that we want them in 3.0.0 or "not at all in beta1" if we decide otherwise. As we are so close to beta1 now we should not have any "let's see if they can make it" features for 3.0.0 anymore. > If they are not characterized as new features, that is a different > matter, of course. The conclusion is that we will have to take some > time (I assume that'll be quick in most cases) thinking how we > characterize certain PRs before beta 1 is released. Yes! -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: 3.0 beta 1 milestone
On 18/09/2020 08:26, Richard Levitte wrote: > On Thu, 17 Sep 2020 15:57:52 +0200, > Tomas Mraz wrote: >> I do not think the milestone should include nice-to-have items. > > Another view is that beta 1 is feature freeze. If those nice to have > items are characterized as new features, then it makes sense to have > them included in the beta 1 milestone if we want them for 3.0.0. > Otherwise, we will have to put them on the waiting list for after > 3.0.0. Not every feature that someone dreams up and creates a PR for should mean we have to hold 3.0 beta 1 until it goes in. There are features that are required, and features that are nice-to-have. If nice-to-have features don't reach approval in time, then they should be dropped from 3.0, and wait for 3.1 instead. Matt > > If they are not characterized as new features, that is a different > matter, of course. The conclusion is that we will have to take some > time (I assume that'll be quick in most cases) thinking how we > characterize certain PRs before beta 1 is released. > > Cheers, > Richard >
Re: 3.0 beta 1 milestone
I've found what's going wrong there, and I agree that it needs to be fixed ASAP, although I don't view it per se as a beta 1 blocker. Either way, a fix is coming up. Cheers, Richard On Thu, 17 Sep 2020 19:21:50 +0200, Dmitry Belyavsky wrote: > > > Dear Matt, > > I think #12891 is a significant problem. I'd suggest fixing it before beta1 > or at least discuss > it. > > Many thanks! > > On Thu, Sep 17, 2020 at 3:48 PM Matt Caswell wrote: > > There's been quite a number of PRs added to the 3.0 beta 1 milestone. > > Within the PRs there are a couple of bug fixes: > > https://github.com/openssl/openssl/pull/12884 > https://github.com/openssl/openssl/pull/12874 > > IMO these would be really nice to get into beta 1, but they should not > be considered blockers for it (i.e. if they didn't go in, it shouldn't > stop us from releasing beta 1). > > There are also some nice-to-have items: > > https://github.com/openssl/openssl/pull/12777 > https://github.com/openssl/openssl/pull/12771 > https://github.com/openssl/openssl/pull/12726 > https://github.com/openssl/openssl/pull/12669 > https://github.com/openssl/openssl/pull/12072 > > Again - these are nice-to-have, and if they happen to get merged in time > for beta 1 then great. Otherwise, they should wait for 3.1 (possibly > things which are just cleanup/minor refactoring could still be done > within the beta period). So, IMO, these should not be considered > blockers either. > > So - this leads me to the question - what is the milestone for? Does it > means these things *must* go in before we can release beta 1? Or does it > mean we would *like* to get these things in for beta 1? > > I actually don't mind either way - but if its the latter, then I need a > way of identifying the "must haves". These are the top priority items, > and at the moment I can't easily track their progress. > > Matt > > -- > SY, Dmitry Belyavsky > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Status of the remaining beta1 PRs
As of right now we have 13 PRs with the beta1 milestone against them. Of these there are 4 which really need our focused attention. These are 2 PRs which are in a state of "written but still in review": WIP: Implement Provider side SM2 Asymmetric Cipher support https://github.com/openssl/openssl/pull/12913 Needed to complete the SM2 support (WIP because dependent on 12536, which is in "approval done" status but not yet merged) ENCODER: Refactor the OSSL_ENCODER API to be more like OSSL_DECODER https://github.com/openssl/openssl/pull/12873 Still in review 1 PR which is in a state of "we really need to do something about this": [WIP, Parked] EVP: Adapt EVP_PKEY_set_alias_type() for provider-native EVP_PKEYs https://github.com/openssl/openssl/pull/12675 Since this affects a public API we probably really do need to figure out what to do with the EVP_PKEY_set_alias_type() 1 PR which is in a state of "its unclear what we do with this": [WIP] Rename some XXX_ex() related methods to XXX_with_libctx() https://github.com/openssl/openssl/pull/12701 With no agreement on a naming convention its unclear if this should go ahead or not The remaining 9 PRs can be split into 2 groups: 6 are in the "approval done" state, so can be pushed soon (one of these we are actually deliberately holding back until nearer the beta release). 3 PRs are in a state of "probably can be dropped altogether": WIP: Fix the DRBG reseed propagation [master] https://github.com/openssl/openssl/pull/12871 This is a bug fix so may not be needed for beta1 at all. Matthias says: "I put the beta1 milestone against it because I wasn't sure whether I need to change some public API or not. Currently, I don't think it's necessary, but I need to check it once more. That will probably not happen before the weekend, but I'll remember to move the ticket from the beta1 milestone to the release milestone, if it's not urgent." Reorder algorithm parameter to be first in *_FETCH() operations. https://github.com/openssl/openssl/pull/12778 Disputed, and probably not needed. Probably can be dropped. RAND: allow the primary, public and private of DRBGs to be overriden and replaced. https://github.com/openssl/openssl/pull/12754 A feature that current discussion on the PR seems to suggest we may drop because it may not be needed for 3.0 after all. Matt
Re: Status of the remaining beta1 PRs
On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote: > > 1 PR which is in a state of "its unclear what we do with this": > [WIP] Rename some XXX_ex() related methods to XXX_with_libctx() > https://github.com/openssl/openssl/pull/12701 > With no agreement on a naming convention its unclear if this should > go > ahead or not We should do something consistent - either rename the _ex functions that just add libctx (and property query) or rename the existing with_libctx functions to _ex functions. The current state is a mess having some functions with _ex and some with _with_libctx. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: Status of the remaining beta1 PRs
On 18/09/2020 16:59, Tomas Mraz wrote: > On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote: >> >> 1 PR which is in a state of "its unclear what we do with this": >> [WIP] Rename some XXX_ex() related methods to XXX_with_libctx() >> https://github.com/openssl/openssl/pull/12701 >> With no agreement on a naming convention its unclear if this should >> go >> ahead or not > > We should do something consistent - either rename the _ex functions > that just add libctx (and property query) or rename the existing > with_libctx functions to _ex functions. > > The current state is a mess having some functions with _ex and some > with _with_libctx. > The current vote on the policy is still ongoing (the subject of this PR is the one covered by chapter 6.2 in the proposed coding style). Unfortunately there is currently no clear outcome on that vote and there are still a significant number of outstanding votes. Without a clear decision one way or another on that vote we cannot decide a way forward. If the vote passes, then it is clear what we have to do. If the vote fails then we will probably have to make a one off vote about what to do about existing _with_libctx vs _ex discrepancies without making a policy out of it. Please can I encourage OTC members to vote one way or the other so that we can move forward. Matt