From levitte at openssl.org Fri Dec 22 08:38:42 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 22 Dec 2017 09:38:42 +0100 (CET) Subject: [openssl-project] As per vote, the project list is created Message-ID: <20171222.093842.494904828507959326.levitte@openssl.org> The vote text is terse and says this: topic: We are going to create a new public mailing list, openssl-project, that will have omc and committers with posting privileges and anyone can subscribe as reader. Discussions and appropriate vote proposals should be on this list. Note that the openssl-omc list should be used for: releases, financials, security (and releases), legal issues, and membership discussions, and personnel issues (like vacation) and all actual voting as well. This votes was passed with seven +1's and one -1, no abstentions. Some of the details are still discussed, and may very well lead to other votes which changes some of the details, or a more precise policy. The intent with this list has already been discussed, but I will recap here. Our intent is for more transparency, making our governance more visible to all our team members (OMC and committers alike), and also to the general public. For all intents and purposes, discussions about the project that isn't about development per se should go on this list primarily. The OMC reserves the right and may choose to have certain discussions on the OMC specific list. That is what the note about what openssl-omc in the vote is about. That note is restrictive, i.e. the OMC *may* *NOT* discuss things that aren't mentioned in that note on openssl-omc. Note that actual OMC voting, at least as off now, will happen on openssl-omc. The vote text as well as the result will be presented here, however, in much the same way as I presented the vote of this list above. [If I got something wrong, please correct me] Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tjh at cryptsoft.com Fri Dec 22 08:45:48 2017 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 22 Dec 2017 18:45:48 +1000 Subject: [openssl-project] As per vote, the project list is created In-Reply-To: <20171222.093842.494904828507959326.levitte@openssl.org> References: <20171222.093842.494904828507959326.levitte@openssl.org> Message-ID: Almost completely correct in my view - except that the list of what can be discussed on openssl-omc is an expected/suggested/anticipated list of topics. It is not a prohibition on other topics. But it is very much the intent to have things as open and as transparent as possible. I do expect this will take some adjustment and we will be asking ourselves and each other whether or not anything going to the OMC list should instead be moved to openssl-project. Tim. On 22 Dec. 2017 6:38 pm, "Richard Levitte" wrote: > The vote text is terse and says this: > > topic: We are going to create a new public mailing list, > openssl-project, that will have omc and committers with posting > privileges and anyone can subscribe as reader. Discussions and > appropriate vote proposals should be on this list. Note that the > openssl-omc list should be used for: releases, financials, > security (and releases), legal issues, and membership discussions, > and personnel issues (like vacation) and all actual voting as > well. > > This votes was passed with seven +1's and one -1, no abstentions. > > Some of the details are still discussed, and may very well lead to > other votes which changes some of the details, or a more precise > policy. > > The intent with this list has already been discussed, but I will recap > here. Our intent is for more transparency, making our governance more > visible to all our team members (OMC and committers alike), and also > to the general public. For all intents and purposes, discussions > about the project that isn't about development per se should go on > this list primarily. > > The OMC reserves the right and may choose to have certain discussions > on the OMC specific list. That is what the note about what > openssl-omc in the vote is about. That note is restrictive, i.e. the > OMC *may* *NOT* discuss things that aren't mentioned in that note on > openssl-omc. > > Note that actual OMC voting, at least as off now, will happen on > openssl-omc. The vote text as well as the result will be presented > here, however, in much the same way as I presented the vote of this > list above. > > [If I got something wrong, please correct me] > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://openssl.org/mailman/listinfo/openssl-project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Fri Dec 22 10:57:38 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 22 Dec 2017 11:57:38 +0100 Subject: [openssl-project] As per vote, the project list is created In-Reply-To: <20171222.093842.494904828507959326.levitte@openssl.org> References: <20171222.093842.494904828507959326.levitte@openssl.org> Message-ID: <20171222105738.GA17869@roeckx.be> You should probably announce this new list more widely Kurt From levitte at openssl.org Fri Dec 22 14:23:36 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 22 Dec 2017 15:23:36 +0100 (CET) Subject: [openssl-project] [openssl-committers] Changing some communication -- opinions? In-Reply-To: References: <4f694df9-3dfe-e3fd-06c0-4d5f25766892@openssl.org> Message-ID: <20171222.152336.1803523764970280875.levitte@openssl.org> [NOTE: since we now have openssl-project, I'm redirecting this discussion there] In message on Fri, 22 Dec 2017 10:31:22 +0000, Matt Caswell said: matt> matt> matt> On 20/12/17 11:37, Andy Polyakov wrote: matt> >>> It's reasonable to reserve an option that is meant to be used matt> >> *occasionally*, i.e. as exception. But as it was presented it looked matt> >> rather as rule than exception. matt> >> matt> >> I think you are focusing too much on specific words; we?re not lawyers. :) matt> > matt> > I don't follow. Are rules and exceptions interchangeable in every day life? matt> > matt> >> We?re trying to do what we think is the right thing ? more openness, more transparency, less separation between the OMC and committers. matt> > matt> > Yes, and I challenge the suggestion to keep major and non-security matt> > release schedules and membership questions out of committers' sight. matt> matt> I agree with that. I didn't think that was the intent of what we matt> discussed (even if the written words say something different). My matt> expectation was that discussion of security releases would be kept matt> private, but discussion about other releases would be on the -project list. I agree regarding releases. On principle, I agree re membership questions as well, but can see reason to have exceptions, at least these: 1. conduct. I'd rather approach someone privately *first*, then discuss withing OMC how to deal, and lastly do a more open callout. 2. voting on new members. I would like to see this happen in the open, buuuut we have to remember that not all of us are primarly associated with the project, but also have employers to deal with. It would be sad if the acceptance or not of new members was affected by external pressure, such as an employers wishes. Keeping that kind of dealing within the OMC doesn't take away the risk, but I think it will diminish it. Item 2 is probably the strongest reason we have to have voting on membership kept within the OMC. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Fri Dec 22 14:28:50 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 22 Dec 2017 15:28:50 +0100 Subject: [openssl-project] Policy update Message-ID: <20171222142850.GA23195@roeckx.be> Hi, During our face 2 face meeting last week we talked about the direction we want to move in, and the policy we'll use to get there. This are the current proposals: - Insecure configuration options shall not be enabled by default; they must be enabled by a compile-time switch. This applies to all new contributions and existing code should be addressed at the next major (1.2.0) release. - All new algorithms must be disableable at compile-time. With the exception of known not-to-work when disabled RSA SHA1 MD5 AES, existing code should be addressed at the next major (1.2.0) release. (PR?s to fix those welcome). - All algorithms and protocols should be recognized by a national or international standards body. This applies to all new contributions and existing code should be addressed at the next major (1.2.0) release. - The EVP interface should be the primary interface for calling crypto operations. All new contributions should only export this API and existing code should be addressed at the next major (1.2.0) release, and might include a compatibility layer. I think at least the wording could be improved. For instance, it says "All [new] algorithms and protocols must be disableable". I assume it means cryptographic algorithms, like AES, SHA2, HMAC, ... Does something like CMS and X509 fall under that? It doesn't sound like an algorithm to me, and protocol also doesn't seem like the correct word. The same goes for the "All algorithms and protocols should be [standardised]". On a related topic, I think there has been a suggestion that we should work on not exposing such compile time options in the public headers but that applications should do runtime detection of the available features instead. Kurt From levitte at openssl.org Fri Dec 22 14:41:54 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 22 Dec 2017 15:41:54 +0100 (CET) Subject: [openssl-project] Policy update In-Reply-To: <20171222142850.GA23195@roeckx.be> References: <20171222142850.GA23195@roeckx.be> Message-ID: <20171222.154154.341283952433546928.levitte@openssl.org> In message <20171222142850.GA23195 at roeckx.be> on Fri, 22 Dec 2017 15:28:50 +0100, Kurt Roeckx said: kurt> Hi, kurt> kurt> During our face 2 face meeting last week we talked about the kurt> direction we want to move in, and the policy we'll use to get kurt> there. This are the current proposals: kurt> - Insecure configuration options shall not be enabled by default; kurt> they must be enabled by a compile-time switch. This applies to all kurt> new contributions and existing code should be addressed at the kurt> next major (1.2.0) release. kurt> - All new algorithms must be disableable at compile-time. With the kurt> exception of known not-to-work when disabled RSA SHA1 MD5 AES, kurt> existing code should be addressed at the next major (1.2.0) kurt> release. (PR?s to fix those welcome). kurt> - All algorithms and protocols should be recognized by a national or kurt> international standards body. This applies to all new kurt> contributions and existing code should be addressed at the next kurt> major (1.2.0) release. kurt> - The EVP interface should be the primary interface for calling kurt> crypto operations. All new contributions should only export this kurt> API and existing code should be addressed at the next major kurt> (1.2.0) release, and might include a compatibility layer. kurt> kurt> I think at least the wording could be improved. For instance, it kurt> says "All [new] algorithms and protocols must be disableable". I kurt> assume it means cryptographic algorithms, like AES, SHA2, HMAC, ... kurt> Does something like CMS and X509 fall under that? It doesn't sound kurt> like an algorithm to me, and protocol also doesn't seem like the kurt> correct word. The same goes for the "All algorithms and protocols kurt> should be [standardised]". I would expect CMS and X509 to fall under the categories "formats" and "protocols", not "algorithms". It *is* unfortunate that crypto/ is such a hodge podge of different things, it really does confuse matters, and I hope we can do some work to separate those things for 1.2.0, at least in different top directories (not necessarely in different libraries, though)... kurt> On a related topic, I think there has been a suggestion that we kurt> should work on not exposing such compile time options in the kurt> public headers but that applications should do runtime detection kurt> of the available features instead. I've a dream (long standing, I think I expressed it as early as 2003) of having all algos as plugins, so the presence of an algo would be defined as the presence of that DSO rather than the present of a macro. That would also make it much easier for the local admin to tune algo availability more dynamically instead of having to rebuild. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Dec 22 14:48:17 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 22 Dec 2017 15:48:17 +0100 (CET) Subject: [openssl-project] As per vote, the project list is created In-Reply-To: <20171222105738.GA17869@roeckx.be> References: <20171222.093842.494904828507959326.levitte@openssl.org> <20171222105738.GA17869@roeckx.be> Message-ID: <20171222.154817.100546507567267849.levitte@openssl.org> In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx said: kurt> You should probably announce this new list more widely Agreed. Wasn't someone going to make a blog post about it? Or was that just a general "we should" where noone actually said "I will"? For if no one feels they've taken that on, I will ;-) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Fri Dec 22 15:00:03 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 22 Dec 2017 15:00:03 +0000 Subject: [openssl-project] As per vote, the project list is created In-Reply-To: <20171222.154817.100546507567267849.levitte@openssl.org> References: <20171222.093842.494904828507959326.levitte@openssl.org> <20171222105738.GA17869@roeckx.be> <20171222.154817.100546507567267849.levitte@openssl.org> Message-ID: <52F2AAA5-4F3E-45D8-A909-A233E66B0F2B@akamai.com> Yes, it was ?we should? not ?I will.? :) Go for it! From matt at openssl.org Fri Dec 22 17:17:17 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 22 Dec 2017 17:17:17 +0000 Subject: [openssl-project] 1.1.1 Release timetable Message-ID: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> The recent f2f meeting gave me the action of pulling together a release timetable for 1.1.1. For the TL;DR summary skip to "1.1.1 Release timetable proposal below". Background ========== I looked back at what we did for 1.1.0. This is the vote that we passed for our original (intended) timetable: The team will adopt the following target dates for the 1.1.0 release. This timetable will be published in the release strategy as "aspirational" (or similar words). 10th December 2015, alpha release 1 7th January 2016, alpha release 2 4th February 2016, alpha release 3 3rd March 2016, 1.1.0 beta 1 release, OpenSSL_1_1_0-stable branch created master becomes 1.1.1 basis 31st March 2016, 1.1.0 beta 2 release 28th April 2016, 1.1.0 public release An alpha release means: - Not (necessarily) feature complete - Not necessarily all new APIs in place yet - Opaque work complete A beta release means: - Feature complete/Feature freeze - Bug fixes only You will notice that those dates are each 4 weeks apart. The reality of what actually happened was somewhat different. We actually achieved this: 10th December 2015, alpha release 1 14th January 2016, alpha release 2 15th February 2016, alpha release 3 16th March 2016, 1.1.0 beta 1 release 19th April 2016, 1.1.0 beta 2 release 4th August 2016, 1.1.0 beta 3 release 25th August 2016, 1.1.0 public release [Aside: Interestingly, from the "old" link of the download page, I only see pre1, pre2 and pre3 available for download. Anyone know what happened to pre4, pre5 and pre6 downloads?] So although we slipped a bit we more or less stuck to the plan until beta2. In April 2016 we were still planning to do a final release after just 2 betas and were targeting 12th May 2016. In early May we started to worry that despite the alpha/beta process we were not ready for a release. Most notably we were concerned about the number of open defects which had been hanging around for a long time. After much debate we defined some release criteria (these were never actually voted on, but this seems to have been the consensus view). The release criteria were: - No open RT tickets more than five years old - No open RT tickets or GitHub PRs/Issues flagged with the 1.1.0 milestone and older than 2 weeks at the time of release (all new tickets prior to release to be assessed and 1.1.0 milestone added if they are relevant to that branch) - Clean builds in Travis, Appveyor and Cisco for two days - run-checker.sh to be showing as clean 2 days before release - No open Coverity issues (not flagged as "False Positive" or "Ignore"). The very late definition of these criteria set us back significantly and we then spent the next few months trying to achieve those criteria. Eventually we decided that we were nearly there, but a lot of time had passed so we decided to add a third beta release. From there things went more or less to plan and we eventually released on 25th August 2016. One other thing that (I think) didn't help was that our first beta release was really more of an alpha. We did not do a feature freeze until beta1, so new stuff was going in all the way up to that release. In my mind a beta release implies some level of stability which we just didn't have at that point in time. Probably we should have called the feature freeze at alpha3 to give things time to settle down before beta1. There are a few different circumstances for 1.1.1 which we need to keep in mind for our release plan. Most importantly we don't know when TLSv1.3 will be finalised. We hope that it won't be long, but we just don't know. The other difference this time around (I think) is that more people seem to be testing 1.1.1 than was the case for 1.1.0. At least that is my perception based on the number of questions/posts/issues/patches etc that we are getting for it. 1.1.1 Release timetable proposal ================================ With all of the above in mind here is my straw man proposal for 1.1.1: 23rd January 2018, alpha release 1 (pre1) 20th February 2018, alpha release 2 (pre2) OpenSSL_1_1_1-stable created (feature freeze) master becomes basis for 1.1.2 or 1.2.0 (TBD) 20th March 2018, beta release 1 (pre3) 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) An alpha release means: - Not (necessarily) feature complete - Not necessarily all new APIs in place yet A beta release means: - Feature complete/Feature freeze - Bug fixes only Note that alpha release 2 may have new features in it, but we will freeze at that point so that beta release 1 will not have new features. My proposed release criteria are: - All open github issues/PRs older than 2 weeks at the time of release to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone to be closed (see below) - Clean builds in Travis and Appveyor for two days - run-checker.sh to be showing as clean 2 days before release - No open Coverity issues (not flagged as "False Positive" or "Ignore") - TLSv1.3 RFC published Valid reasons for closing an issue/PR with a 1.1.1 milestone might be: - We have just now or sometime in the past fixed the issue - Unable to reproduce (following discussion with original reporter if possible) - Working as intended - Deliberate decision not to fix until a later release - Not enough information and unable to contact reporter - etc With this plan my expectation is that from 20th February (feature freeze) the focus will shift from features to closing off open issues/PRs. By doing so much earlier than with 1.1.0 I hope to avoid the drawn out release timetable. If the TLSv1.3 RFC is not published by the time we are ready to release, or we haven't made the progress we want on the other release criteria then we can add additional betas as we see fit until such time as we are ready. Matt From rsalz at akamai.com Fri Dec 22 17:52:00 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 22 Dec 2017 17:52:00 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> Message-ID: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> I would like to make Alpha 1 be early January, and Beta 1 by mid-February. That makes the release in mid-March. That assumes the IETF hands the TLS 1.3 spec to the IESG for final review in February. From matt at openssl.org Fri Dec 22 18:10:05 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 22 Dec 2017 18:10:05 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> Message-ID: <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> On 22/12/17 17:52, Salz, Rich wrote: > I would like to make Alpha 1 be early January, and Beta 1 by > mid-February. That makes the release in mid-March. That assumes the > IETF hands the TLS 1.3 spec to the IESG for final review in > February. I think compressing the release cadence to less than 4 weeks (which is implied by your suggestion) is overly ambitious and could be setting ourselves up to fail. If you want to bring the final release date earlier then one possibility is to drop the second alpha release, so the timetable becomes: 23rd January 2018, alpha release 1 (pre1) OpenSSL_1_1_1-stable created (feature freeze) master becomes basis for 1.1.2 or 1.2.0 (TBD) 20th February 2018, beta release 1 (pre2) 20th March 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) Doing it that way still gives us the best part of 2 months to work on the release criteria (i.e. closing off old issues). Another option is to relax the release criteria, so we need less time to work on them. The problems with this approach are: - we would now only be doing 2 pre-releases. Is that enough for things to settle down and for us to be confident we have sufficient feedback? - Feature freeze becomes 23rd January which gives us very little time to get the final features in (although having said that the only real MUST haves are the QUIC stuff, i.e. stateless stuff and early exporter support) When do you realistically expect the final RFC publication to be? Given past performance I am not hopeful of seeing it in Q1. I would prefer to take our time a little more and see a release that we are confident in, rather than one we have rushed out. Even if that means the release doesn't go out until a month after TLSv1.3 RFC is published. Matt From rsalz at akamai.com Fri Dec 22 18:16:14 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 22 Dec 2017 18:16:14 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> Message-ID: <4708C7D2-C63B-4460-AC97-F8EE7E6B3A5E@akamai.com> Dropping the second alpha as a way to bring in the release date is okay, but I don?t have anything that would have to be in the end-of-January freeze. Given how little feedback we got during our extended pre-release periods for 1.1.0 I don?t think we need a lot of time. According to email I had with one of the Security AD?s, she wants the TLS WG to be done in January, and then a month for IESG review. Allowing for slippage that means March. But nobody knows for sure. From levitte at openssl.org Fri Dec 22 18:43:14 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 22 Dec 2017 19:43:14 +0100 (CET) Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> Message-ID: <20171222.194314.692026547359855772.levitte@openssl.org> In message <455316cf-cc58-c102-e723-eaaf89b21b96 at openssl.org> on Fri, 22 Dec 2017 17:17:17 +0000, Matt Caswell said: ... matt> 1.1.1 Release timetable proposal matt> ================================ matt> matt> With all of the above in mind here is my straw man proposal for 1.1.1: matt> matt> 23rd January 2018, alpha release 1 (pre1) matt> 20th February 2018, alpha release 2 (pre2) matt> OpenSSL_1_1_1-stable created (feature freeze) matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) matt> 20th March 2018, beta release 1 (pre3) matt> 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) matt> matt> An alpha release means: matt> - Not (necessarily) feature complete matt> - Not necessarily all new APIs in place yet matt> matt> A beta release means: matt> - Feature complete/Feature freeze matt> - Bug fixes only matt> matt> Note that alpha release 2 may have new features in it, but we will matt> freeze at that point so that beta release 1 will not have new features. That is perfectly contradictory. You write it yourself, and alpha release means "Not (necessarely) feature complete", but if you do a feature freeze with alpha 2, then there's no space to complete the features that may remain. So in practice, you're making alpha 2 a beta. I am *strictly* opposed to this confusing message. In message <1b61a29b-035e-9786-c8e9-d3feb0888340 at openssl.org> on Fri, 22 Dec 2017 18:10:05 +0000, Matt Caswell said: matt> I think compressing the release cadence to less than 4 weeks (which is matt> implied by your suggestion) is overly ambitious and could be setting matt> ourselves up to fail. If you want to bring the final release date matt> earlier then one possibility is to drop the second alpha release, so the matt> timetable becomes: matt> matt> 23rd January 2018, alpha release 1 (pre1) matt> OpenSSL_1_1_1-stable created (feature freeze) matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) matt> 20th February 2018, beta release 1 (pre2) matt> 20th March 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) matt> matt> Doing it that way still gives us the best part of 2 months to work on matt> the release criteria (i.e. closing off old issues). Another option is to matt> relax the release criteria, so we need less time to work on them. And with this, you're proposing that our release cycle starts with a beta in practice, no matter what you call it. I am *brutally* opposed to this plan. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tjh at cryptsoft.com Fri Dec 22 20:04:07 2017 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 23 Dec 2017 06:04:07 +1000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <20171222.194314.692026547359855772.levitte@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171222.194314.692026547359855772.levitte@openssl.org> Message-ID: I think Richard meant to state vehemently rather than brutally ... Tim. On Sat, Dec 23, 2017 at 4:43 AM, Richard Levitte wrote: > In message <455316cf-cc58-c102-e723-eaaf89b21b96 at openssl.org> on Fri, 22 > Dec 2017 17:17:17 +0000, Matt Caswell said: > > ... > matt> 1.1.1 Release timetable proposal > matt> ================================ > matt> > matt> With all of the above in mind here is my straw man proposal for > 1.1.1: > matt> > matt> 23rd January 2018, alpha release 1 (pre1) > matt> 20th February 2018, alpha release 2 (pre2) > matt> OpenSSL_1_1_1-stable created (feature freeze) > matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) > matt> 20th March 2018, beta release 1 (pre3) > matt> 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is > published) > matt> > matt> An alpha release means: > matt> - Not (necessarily) feature complete > matt> - Not necessarily all new APIs in place yet > matt> > matt> A beta release means: > matt> - Feature complete/Feature freeze > matt> - Bug fixes only > matt> > matt> Note that alpha release 2 may have new features in it, but we will > matt> freeze at that point so that beta release 1 will not have new > features. > > That is perfectly contradictory. You write it yourself, and alpha > release means "Not (necessarely) feature complete", but if you do a > feature freeze with alpha 2, then there's no space to complete the > features that may remain. So in practice, you're making alpha 2 a > beta. I am *strictly* opposed to this confusing message. > > In message <1b61a29b-035e-9786-c8e9-d3feb0888340 at openssl.org> on Fri, 22 > Dec 2017 18:10:05 +0000, Matt Caswell said: > > matt> I think compressing the release cadence to less than 4 weeks (which > is > matt> implied by your suggestion) is overly ambitious and could be setting > matt> ourselves up to fail. If you want to bring the final release date > matt> earlier then one possibility is to drop the second alpha release, so > the > matt> timetable becomes: > matt> > matt> 23rd January 2018, alpha release 1 (pre1) > matt> OpenSSL_1_1_1-stable created (feature freeze) > matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) > matt> 20th February 2018, beta release 1 (pre2) > matt> 20th March 2018, 1.1.1 public release (assuming TLSv1.3 RFC is > published) > matt> > matt> Doing it that way still gives us the best part of 2 months to work on > matt> the release criteria (i.e. closing off old issues). Another option > is to > matt> relax the release criteria, so we need less time to work on them. > > And with this, you're proposing that our release cycle starts with a > beta in practice, no matter what you call it. I am *brutally* opposed > to this plan. > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Dec 22 20:27:44 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 22 Dec 2017 15:27:44 -0500 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <20171222.194314.692026547359855772.levitte@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <20171222.194314.692026547359855772.levitte@openssl.org> Message-ID: <9A2EA031-46EE-4058-918C-D78290351ECA@dukhovni.org> > On Dec 22, 2017, at 1:43 PM, Richard Levitte wrote: > > That is perfectly contradictory. You write it yourself, and alpha > release means "Not (necessarely) feature complete", but if you do a > feature freeze with alpha 2, then there's no space to complete the > features that may remain. So in practice, you're making alpha 2 a > beta. I am *strictly* opposed to this confusing message. Yep, I agree, feature freeze begins when the first beta is shipped, not the last alpha. -- Viktor. From matt at openssl.org Sat Dec 23 00:32:07 2017 From: matt at openssl.org (Matt Caswell) Date: Sat, 23 Dec 2017 00:32:07 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <20171222.194314.692026547359855772.levitte@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <20171222.194314.692026547359855772.levitte@openssl.org> Message-ID: On 22/12/17 18:43, Richard Levitte wrote: > In message <455316cf-cc58-c102-e723-eaaf89b21b96 at openssl.org> on Fri, 22 Dec 2017 17:17:17 +0000, Matt Caswell said: > > ... > matt> 1.1.1 Release timetable proposal > matt> ================================ > matt> > matt> With all of the above in mind here is my straw man proposal for 1.1.1: > matt> > matt> 23rd January 2018, alpha release 1 (pre1) > matt> 20th February 2018, alpha release 2 (pre2) > matt> OpenSSL_1_1_1-stable created (feature freeze) > matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) > matt> 20th March 2018, beta release 1 (pre3) > matt> 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) > matt> > matt> An alpha release means: > matt> - Not (necessarily) feature complete > matt> - Not necessarily all new APIs in place yet > matt> > matt> A beta release means: > matt> - Feature complete/Feature freeze > matt> - Bug fixes only > matt> > matt> Note that alpha release 2 may have new features in it, but we will > matt> freeze at that point so that beta release 1 will not have new features. > > That is perfectly contradictory. You write it yourself, and alpha > release means "Not (necessarely) feature complete", but if you do a > feature freeze with alpha 2, then there's no space to complete the > features that may remain. So in practice, you're making alpha 2 a > beta. I am *strictly* opposed to this confusing message. Your way seems even more confusing (to me). Looking at this from a user's perspective, if we say that a beta release has no new features and only contains bug fixes, then this implies "since the last release". Therefore the logical conclusion is that beta rules apply from the beginning of the development phase for that release. The development phase for the beta release starts as soon as the last alpha is done. Therefore the feature freeze should apply from that point. > > In message <1b61a29b-035e-9786-c8e9-d3feb0888340 at openssl.org> on Fri, 22 Dec 2017 18:10:05 +0000, Matt Caswell said: > > matt> I think compressing the release cadence to less than 4 weeks (which is > matt> implied by your suggestion) is overly ambitious and could be setting > matt> ourselves up to fail. If you want to bring the final release date > matt> earlier then one possibility is to drop the second alpha release, so the > matt> timetable becomes: > matt> > matt> 23rd January 2018, alpha release 1 (pre1) > matt> OpenSSL_1_1_1-stable created (feature freeze) > matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) > matt> 20th February 2018, beta release 1 (pre2) > matt> 20th March 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) > matt> > matt> Doing it that way still gives us the best part of 2 months to work on > matt> the release criteria (i.e. closing off old issues). Another option is to > matt> relax the release criteria, so we need less time to work on them. > > And with this, you're proposing that our release cycle starts with a > beta in practice, no matter what you call it. I am *brutally* opposed > to this plan. > Well, I am not enthused by this version of the plan either. It was only put forward as a possible way of achieving Rich's desire for a March public release. I think my initial plan version with the extra alpha release is better. I've not yet heard a justification for why we should be targeting March. If it's to line up with the earliest reasonable date that we expect the TLS1.3 RFC to be published then that doesn't seem like a good enough reason to me. Matt From matt at openssl.org Sat Dec 23 00:40:33 2017 From: matt at openssl.org (Matt Caswell) Date: Sat, 23 Dec 2017 00:40:33 +0000 Subject: [openssl-project] Red Hat Podcast interview Message-ID: <0a1e2a47-9dc2-e7c9-f47b-8bd7dc0113f2@openssl.org> FYI, I have been invited to take part in a podcast for Red Hat. They are working on a series of episodes one of which will be focused on security. They are coming to record the audio in early January. Not sure when the episode will be made available but I'll let you know when I find out. Matt From levitte at openssl.org Sat Dec 23 00:56:06 2017 From: levitte at openssl.org (Richard Levitte) Date: Sat, 23 Dec 2017 01:56:06 +0100 (CET) Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <20171222.194314.692026547359855772.levitte@openssl.org> Message-ID: <20171223.015606.1657743103467198156.levitte@openssl.org> In message on Sat, 23 Dec 2017 00:32:07 +0000, Matt Caswell said: matt> matt> matt> On 22/12/17 18:43, Richard Levitte wrote: matt> > In message <455316cf-cc58-c102-e723-eaaf89b21b96 at openssl.org> on Fri, 22 Dec 2017 17:17:17 +0000, Matt Caswell said: matt> > matt> > ... matt> > matt> 1.1.1 Release timetable proposal matt> > matt> ================================ matt> > matt> matt> > matt> With all of the above in mind here is my straw man proposal for 1.1.1: matt> > matt> matt> > matt> 23rd January 2018, alpha release 1 (pre1) matt> > matt> 20th February 2018, alpha release 2 (pre2) matt> > matt> OpenSSL_1_1_1-stable created (feature freeze) matt> > matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) matt> > matt> 20th March 2018, beta release 1 (pre3) matt> > matt> 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) matt> > matt> matt> > matt> An alpha release means: matt> > matt> - Not (necessarily) feature complete matt> > matt> - Not necessarily all new APIs in place yet matt> > matt> matt> > matt> A beta release means: matt> > matt> - Feature complete/Feature freeze matt> > matt> - Bug fixes only matt> > matt> matt> > matt> Note that alpha release 2 may have new features in it, but we will matt> > matt> freeze at that point so that beta release 1 will not have new features. matt> > matt> > That is perfectly contradictory. You write it yourself, and alpha matt> > release means "Not (necessarely) feature complete", but if you do a matt> > feature freeze with alpha 2, then there's no space to complete the matt> > features that may remain. So in practice, you're making alpha 2 a matt> > beta. I am *strictly* opposed to this confusing message. matt> matt> Your way seems even more confusing (to me). matt> matt> Looking at this from a user's perspective, if we say that a beta release matt> has no new features and only contains bug fixes, then this implies matt> "since the last release". Therefore the logical conclusion is that beta matt> rules apply from the beginning of the development phase for that matt> release. The development phase for the beta release starts as soon as matt> the last alpha is done. Therefore the feature freeze should apply from matt> that point. I disagree with your interpretation. Mine is that going into beta means "From this point on, there will be no more added features", which is essentially what a feature freeze means, and that is also what people usually mean. Ref: https://en.wikipedia.org/wiki/Software_release_life_cycle Note that in that article, they say this about the Alpha phase: "The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software." The last alpha release doesn't mark the end of an alpha phase, the first beta does. "Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs." This is what people expect when you say alpha and beta, and this is how we have behaved before. Why we should act differently now is a mystery to me... or well, I can see that there's a desire to rush things because of the anticipated publication of TLS 1.3. However, I think it's the wrong move, and even more so by blurring the usual meaning of alpha and beta. matt> > In message <1b61a29b-035e-9786-c8e9-d3feb0888340 at openssl.org> on Fri, 22 Dec 2017 18:10:05 +0000, Matt Caswell said: matt> > matt> > matt> I think compressing the release cadence to less than 4 weeks (which is matt> > matt> implied by your suggestion) is overly ambitious and could be setting matt> > matt> ourselves up to fail. If you want to bring the final release date matt> > matt> earlier then one possibility is to drop the second alpha release, so the matt> > matt> timetable becomes: matt> > matt> matt> > matt> 23rd January 2018, alpha release 1 (pre1) matt> > matt> OpenSSL_1_1_1-stable created (feature freeze) matt> > matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) matt> > matt> 20th February 2018, beta release 1 (pre2) matt> > matt> 20th March 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) matt> > matt> matt> > matt> Doing it that way still gives us the best part of 2 months to work on matt> > matt> the release criteria (i.e. closing off old issues). Another option is to matt> > matt> relax the release criteria, so we need less time to work on them. matt> > matt> > And with this, you're proposing that our release cycle starts with a matt> > beta in practice, no matter what you call it. I am *brutally* opposed matt> > to this plan. matt> > matt> matt> Well, I am not enthused by this version of the plan either. It was only matt> put forward as a possible way of achieving Rich's desire for a March matt> public release. I think my initial plan version with the extra alpha matt> release is better. I've not yet heard a justification for why we should matt> be targeting March. If it's to line up with the earliest reasonable date matt> that we expect the TLS1.3 RFC to be published then that doesn't seem matt> like a good enough reason to me. Thank you, we seem to agree. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Sat Dec 23 01:16:51 2017 From: matt at openssl.org (Matt Caswell) Date: Sat, 23 Dec 2017 01:16:51 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <20171223.015606.1657743103467198156.levitte@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <20171222.194314.692026547359855772.levitte@openssl.org> <20171223.015606.1657743103467198156.levitte@openssl.org> Message-ID: <80d107e6-ba7e-457a-e569-13f0f356c54b@openssl.org> On 23/12/17 00:56, Richard Levitte wrote: > In message on Sat, 23 Dec 2017 00:32:07 +0000, Matt Caswell said: > > matt> > matt> > matt> On 22/12/17 18:43, Richard Levitte wrote: > matt> > In message <455316cf-cc58-c102-e723-eaaf89b21b96 at openssl.org> on Fri, 22 Dec 2017 17:17:17 +0000, Matt Caswell said: > matt> > > matt> > ... > matt> > matt> 1.1.1 Release timetable proposal > matt> > matt> ================================ > matt> > matt> > matt> > matt> With all of the above in mind here is my straw man proposal for 1.1.1: > matt> > matt> > matt> > matt> 23rd January 2018, alpha release 1 (pre1) > matt> > matt> 20th February 2018, alpha release 2 (pre2) > matt> > matt> OpenSSL_1_1_1-stable created (feature freeze) > matt> > matt> master becomes basis for 1.1.2 or 1.2.0 (TBD) > matt> > matt> 20th March 2018, beta release 1 (pre3) > matt> > matt> 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) > matt> > matt> > matt> > matt> An alpha release means: > matt> > matt> - Not (necessarily) feature complete > matt> > matt> - Not necessarily all new APIs in place yet > matt> > matt> > matt> > matt> A beta release means: > matt> > matt> - Feature complete/Feature freeze > matt> > matt> - Bug fixes only > matt> > matt> > matt> > matt> Note that alpha release 2 may have new features in it, but we will > matt> > matt> freeze at that point so that beta release 1 will not have new features. > matt> > > matt> > That is perfectly contradictory. You write it yourself, and alpha > matt> > release means "Not (necessarely) feature complete", but if you do a > matt> > feature freeze with alpha 2, then there's no space to complete the > matt> > features that may remain. So in practice, you're making alpha 2 a > matt> > beta. I am *strictly* opposed to this confusing message. > matt> > matt> Your way seems even more confusing (to me). > matt> > matt> Looking at this from a user's perspective, if we say that a beta release > matt> has no new features and only contains bug fixes, then this implies > matt> "since the last release". Therefore the logical conclusion is that beta > matt> rules apply from the beginning of the development phase for that > matt> release. The development phase for the beta release starts as soon as > matt> the last alpha is done. Therefore the feature freeze should apply from > matt> that point. > > I disagree with your interpretation. Mine is that going into beta > means "From this point on, there will be no more added features", > which is essentially what a feature freeze means, and that is also > what people usually mean. > > Ref: https://en.wikipedia.org/wiki/Software_release_life_cycle > > Note that in that article, they say this about the Alpha phase: "The > alpha phase usually ends with a feature freeze, indicating that no > more features will be added to the software." > > The last alpha release doesn't mark the end of an alpha phase, the > first beta does. > > "Beta phase generally begins when the software is feature complete but > likely to contain a number of known or unknown bugs." > > This is what people expect when you say alpha and beta, and this is > how we have behaved before. Why we should act differently now is a > mystery to me... or well, I can see that there's a desire to rush > things because of the anticipated publication of TLS 1.3. However, I > think it's the wrong move, and even more so by blurring the usual > meaning of alpha and beta. This has nothing to do with a desire to rush things (far from it). If anything the opposite. It comes from my perception that in 1.1.0 we had too many unstable releases and too few stable ones. In part I view this was because the first beta was not in fact stable, but was unstable because of last minute feature additions which goes contrary to my view about what a beta release should be about. Ultimately though if the team view is that feature freeze starts with beta 1 then the same effect can be achieved by relabelling the releases in my original plan: 23rd January 2018, alpha release 1 (pre1) 20th February 2018, beta release 1 (pre2) OpenSSL_1_1_1-stable created (feature freeze) master becomes basis for 1.1.2 or 1.2.0 (TBD) 20th March 2018, beta release 2 (pre3) 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) Matt From kaduk at mit.edu Sat Dec 23 05:53:20 2017 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 22 Dec 2017 23:53:20 -0600 Subject: [openssl-project] Policy update In-Reply-To: <20171222142850.GA23195@roeckx.be> References: <20171222142850.GA23195@roeckx.be> Message-ID: <20171223055320.GX39477@kduck.kaduk.org> On Fri, Dec 22, 2017 at 03:28:50PM +0100, Kurt Roeckx wrote: > > I think at least the wording could be improved. For instance, it > says "All [new] algorithms and protocols must be disableable". I > assume it means cryptographic algorithms, like AES, SHA2, HMAC, ... > Does something like CMS and X509 fall under that? It doesn't sound > like an algorithm to me, and protocol also doesn't seem like the > correct word. The same goes for the "All algorithms and protocols > should be [standardised]". > > On a related topic, I think there has been a suggestion that we > should work on not exposing such compile time options in the > public headers but that applications should do runtime detection > of the available features instead. I agree with these concerns about exposing the compile-time options in the public headers, but I also have concerns about the number of compile-time options in general. Growth of compile-time options brings *exponential* growth in the number of possible "supported" configurations, which places a huge maintenance burden on us. Do we really need to take on that burden? -Ben From kurt at roeckx.be Sat Dec 23 09:30:57 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 23 Dec 2017 10:30:57 +0100 Subject: [openssl-project] Policy update In-Reply-To: <20171223055320.GX39477@kduck.kaduk.org> References: <20171222142850.GA23195@roeckx.be> <20171223055320.GX39477@kduck.kaduk.org> Message-ID: <20171223093056.GA25146@roeckx.be> On Fri, Dec 22, 2017 at 11:53:20PM -0600, Benjamin Kaduk wrote: > On Fri, Dec 22, 2017 at 03:28:50PM +0100, Kurt Roeckx wrote: > > > > I think at least the wording could be improved. For instance, it > > says "All [new] algorithms and protocols must be disableable". I > > assume it means cryptographic algorithms, like AES, SHA2, HMAC, ... > > Does something like CMS and X509 fall under that? It doesn't sound > > like an algorithm to me, and protocol also doesn't seem like the > > correct word. The same goes for the "All algorithms and protocols > > should be [standardised]". > > > > On a related topic, I think there has been a suggestion that we > > should work on not exposing such compile time options in the > > public headers but that applications should do runtime detection > > of the available features instead. > > I agree with these concerns about exposing the compile-time options > in the public headers, but I also have concerns about the number of > compile-time options in general. Growth of compile-time options > brings *exponential* growth in the number of possible "supported" > configurations, which places a huge maintenance burden on us. Do we > really need to take on that burden? They currently break often, like don't compile or the test suite doesn't skip them, because we don't test them all, but they've all been easy to fix. Maybe we should also say that only the default options are supported? Kurt From rsalz at akamai.com Sat Dec 23 16:47:04 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 23 Dec 2017 16:47:04 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <20171223.015606.1657743103467198156.levitte@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <20171222.194314.692026547359855772.levitte@openssl.org> <20171223.015606.1657743103467198156.levitte@openssl.org> Message-ID: <5D9BAA77-0661-4DFD-9CFB-C356F565FB72@akamai.com> ? The last alpha release doesn't mark the end of an alpha phase, the first beta does. ? "Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs." I agree with Richard. I have never heard Matt?s interpretation anywhere From rsalz at akamai.com Sat Dec 23 17:10:05 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 23 Dec 2017 17:10:05 +0000 Subject: [openssl-project] openssl.com website now live Message-ID: <9882D4B1-D3B8-4789-97AB-C29A62A469B3@akamai.com> The new openssl.com website is now up. It is very simple, very stark, very ugly. It provides all the needed information, and makes it clear that OSS is not openssl. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Sun Dec 24 06:09:33 2017 From: kaduk at mit.edu (Benjamin Kaduk) Date: Sun, 24 Dec 2017 00:09:33 -0600 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> References: <455316cf-cc58-c102-e723-eaaf89b21b96@openssl.org> <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> Message-ID: <20171224060933.GZ39477@kduck.kaduk.org> On Fri, Dec 22, 2017 at 06:10:05PM +0000, Matt Caswell wrote: > > > > When do you realistically expect the final RFC publication to be? Given > past performance I am not hopeful of seeing it in Q1. I also am not hopeful of seeing it in Q1; April seems more realistic to me. > I would prefer to take our time a little more and see a release that we > are confident in, rather than one we have rushed out. Even if that means > the release doesn't go out until a month after TLSv1.3 RFC is published. I agree -- the IETF does not prohibit itself from making changes to the document up until it's published as an RFC, and locking ourselves into a release cadence that prevents us from making changes seems to be tying our hands for negligible gain. -Ben From levitte at openssl.org Mon Dec 25 11:14:11 2017 From: levitte at openssl.org (Richard Levitte) Date: Mon, 25 Dec 2017 12:14:11 +0100 (CET) Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <20171224060933.GZ39477@kduck.kaduk.org> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> Message-ID: <20171225.121411.190562330569812696.levitte@openssl.org> In message <20171224060933.GZ39477 at kduck.kaduk.org> on Sun, 24 Dec 2017 00:09:33 -0600, Benjamin Kaduk said: kaduk> > I would prefer to take our time a little more and see a release that we kaduk> > are confident in, rather than one we have rushed out. Even if that means kaduk> > the release doesn't go out until a month after TLSv1.3 RFC is published. kaduk> kaduk> I agree -- the IETF does not prohibit itself from making changes to kaduk> the document up until it's published as an RFC, and locking kaduk> ourselves into a release cadence that prevents us from making kaduk> changes seems to be tying our hands for negligible gain. +1 (enthusiastically) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Mon Dec 25 22:17:57 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 25 Dec 2017 22:17:57 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <20171225.121411.190562330569812696.levitte@openssl.org> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> Message-ID: A month, if we?re already in BETA, is okay. More than that is bad and could force people to move to boring. We should plan for a release in March and if it slips because TLS 1.3 isn?t ready, that?s fine. From kurt at roeckx.be Tue Dec 26 10:41:35 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 26 Dec 2017 11:41:35 +0100 Subject: [openssl-project] As per vote, the project list is created In-Reply-To: <20171222.154817.100546507567267849.levitte@openssl.org> References: <20171222.093842.494904828507959326.levitte@openssl.org> <20171222105738.GA17869@roeckx.be> <20171222.154817.100546507567267849.levitte@openssl.org> Message-ID: <20171226104135.GA30326@roeckx.be> On Fri, Dec 22, 2017 at 03:48:17PM +0100, Richard Levitte wrote: > In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx said: > > kurt> You should probably announce this new list more widely > > Agreed. Wasn't someone going to make a blog post about it? Or was > that just a general "we should" where noone actually said "I will"? > For if no one feels they've taken that on, I will ;-) Richard, I think we're waiting for you. I suggest you mail about this, I think that will reach most of the people. Kurt From levitte at openssl.org Tue Dec 26 13:11:55 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 26 Dec 2017 14:11:55 +0100 Subject: [openssl-project] As per vote, the project list is created In-Reply-To: <20171226104135.GA30326@roeckx.be> References: <20171222.093842.494904828507959326.levitte@openssl.org> <20171222105738.GA17869@roeckx.be> <20171222.154817.100546507567267849.levitte@openssl.org> <20171226104135.GA30326@roeckx.be> Message-ID: Yup. Today is still holyday, though, and my mom's birthday to boot, so I will have you wait a liiiittle bit longer. Cheers Richard Kurt Roeckx skrev: (26 december 2017 11:41:35 CET) >On Fri, Dec 22, 2017 at 03:48:17PM +0100, Richard Levitte wrote: >> In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017 >11:57:38 +0100, Kurt Roeckx said: >> >> kurt> You should probably announce this new list more widely >> >> Agreed. Wasn't someone going to make a blog post about it? Or was >> that just a general "we should" where noone actually said "I will"? >> For if no one feels they've taken that on, I will ;-) > >Richard, I think we're waiting for you. > >I suggest you mail about this, I think that will reach most of the >people. > > >Kurt > >_______________________________________________ >openssl-project mailing list >openssl-project at openssl.org >https://mta.openssl.org/mailman/listinfo/openssl-project -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From matt at openssl.org Wed Dec 27 09:21:23 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Dec 2017 09:21:23 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> Message-ID: <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> On 25/12/17 22:17, Salz, Rich wrote: > A month, if we?re already in BETA, is okay. More than that is bad and could force people to move to boring. > > We should plan for a release in March and if it slips because TLS 1.3 isn?t ready, that?s fine. I really think March is too ambitious and is just setting ourselves up to fail. We should set an achievable goal and, IMO, March is not achievable (at least not with the release criteria as I proposed them). There has not been much discussion on the proposed release criteria BTW. Any opinions on those. Repeated here for ease of reference: - All open github issues/PRs older than 2 weeks at the time of release to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone to be closed (see below) - Clean builds in Travis and Appveyor for two days - run-checker.sh to be showing as clean 2 days before release - No open Coverity issues (not flagged as "False Positive" or "Ignore") - TLSv1.3 RFC published Valid reasons for closing an issue/PR with a 1.1.1 milestone might be: - We have just now or sometime in the past fixed the issue - Unable to reproduce (following discussion with original reporter if possible) - Working as intended - Deliberate decision not to fix until a later release - Not enough information and unable to contact reporter - etc The work here is that I state *all* open github issues/PRs older than 2 weeks and relevant to 1.1.1 to be addressed. We currently have >500 of these (of which some may not be relevant to 1.1.1). Matt From rsalz at akamai.com Wed Dec 27 13:45:15 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Dec 2017 13:45:15 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> Message-ID: <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> ? - All open github issues/PRs older than 2 weeks at the time of release to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone to be closed (see below) I think this is no longer appropriate, since we migrated RT to GH issues and we are encouraging (soon to be public) everything to be put on GH. Any flagged issue, yes, but two weeks is way too short. From matt at openssl.org Wed Dec 27 14:43:18 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Dec 2017 14:43:18 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> Message-ID: <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> On 27/12/17 13:45, Salz, Rich wrote: > ? - All open github issues/PRs older than 2 weeks at the time of > release to be assessed for relevance to 1.1.1. Any flagged with the > 1.1.1 milestone to be closed (see below) > > I think this is no longer appropriate, since we migrated RT to GH > issues and we are encouraging (soon to be public) everything to be > put on GH. Any flagged issue, yes, but two weeks is way too short. I'm not sure I understand the relevance of the migration of RT to GH issues to your point? The 2 week thing basically says we can ignore any really new issues when deciding whether we are ready to release. That was what we did for 1.1.0 and was on the basis that we constantly get new issues raised so if we have to fix everything before we do a release then we could find ourselves in a situation where we are just about to do a release and at the last minute someone raises a new issue and we are obliged by the release criteria to fix it before we can complete the release. We could change that to say we will only worry about issues raised more than (say) 4 weeks ago. The problem with that is that we are planning to do the final release 4 weeks after the last beta. That would mean that the release criteria would allow us to effectively ignore any issues raised during the last beta period - which kind of defeats the point of having a beta period. Or am I misunderstanding your point? Matt From rsalz at akamai.com Wed Dec 27 16:01:13 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Dec 2017 16:01:13 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> Message-ID: <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> ? I'm not sure I understand the relevance of the migration of RT to GH issues to your point? There are hundreds of issue in GH now that weren?t in GH in the previous releases. Our rate-of-issues-raised is going up. I think rather than say ?we?ll address everything older than ?n?? we should say ?we?ll address everything tagged with ?x?? That is a much more realistic criteria. Or do you really want to commit to closing all RT bugs more than a year old? Since they?re all more than a year old at this point. Is that more clear? From openssl-users at dukhovni.org Wed Dec 27 16:04:35 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 27 Dec 2017 11:04:35 -0500 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> Message-ID: <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> > On Dec 27, 2017, at 11:01 AM, Salz, Rich wrote: > > Our rate-of-issues-raised is going up. I think rather than say ?we?ll address everything older than ?n?? we should say ?we?ll address everything tagged with ?x?? That's what Matt's email says, but it also requires the issues to be assessed and explicitly deferred to a later release if not to be resolved in 1.1.1. -- Viktor. From matt at openssl.org Wed Dec 27 16:32:57 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Dec 2017 16:32:57 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> Message-ID: <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> On 27/12/17 16:04, Viktor Dukhovni wrote: > > >> On Dec 27, 2017, at 11:01 AM, Salz, Rich wrote: >> >> Our rate-of-issues-raised is going up. I think rather than say ?we?ll address everything older than ?n?? we should say ?we?ll address everything tagged with ?x?? > > That's what Matt's email says, but it also requires the issues > to be assessed and explicitly deferred to a later release if > not to be resolved in 1.1.1. > Yes, exactly. The idea was we assess everything and mark ones to be addressed for 1.1.1. Any of those should be closed by the time we release. Matt From rsalz at akamai.com Wed Dec 27 22:17:22 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Dec 2017 22:17:22 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> Message-ID: Yes, exactly. The idea was we assess everything and mark ones to be addressed for 1.1.1. Any of those should be closed by the time we release. That was not clear to me from the description. So you mean this? We will review all open issues created more than two weeks before the release date, and any tagged for 1.1.1 must be closed for the release. From matt at openssl.org Thu Dec 28 08:58:42 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Dec 2017 08:58:42 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> Message-ID: On 27/12/17 22:17, Salz, Rich wrote: > > Yes, exactly. The idea was we assess everything and mark ones to be > addressed for 1.1.1. Any of those should be closed by the time we release. > > That was not clear to me from the description. So you mean this? > We will review all open issues created more than two weeks before the release date, and any tagged for 1.1.1 must be closed for the release. Yes. Assuming that an outcome from "review all open issues" would be the tagging of some issues with 1.1.1. Matt From tjh at cryptsoft.com Thu Dec 28 09:24:07 2017 From: tjh at cryptsoft.com (Tim Hudson) Date: Thu, 28 Dec 2017 19:24:07 +1000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> Message-ID: How about we get the review-all-issues part sorted out so we can quantify the scope of effort to resolve. Right now without that information we really don't know how much additional work is being taken on - and hence how much scope increase this is. Tim. On Thu, Dec 28, 2017 at 6:58 PM, Matt Caswell wrote: > > > On 27/12/17 22:17, Salz, Rich wrote: > > > > Yes, exactly. The idea was we assess everything and mark ones to be > > addressed for 1.1.1. Any of those should be closed by the time we > release. > > > > That was not clear to me from the description. So you mean this? > > We will review all open issues created more than two weeks before > the release date, and any tagged for 1.1.1 must be closed for the release. > > Yes. Assuming that an outcome from "review all open issues" would be the > tagging of some issues with 1.1.1. > > Matt > > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Dec 28 21:01:42 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 28 Dec 2017 21:01:42 +0000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> Message-ID: <7D5A5CAF-571C-4B45-A88A-5BA24D6F86EA@akamai.com> If I?m the only one confused by the original wording, then leave it. On 12/28/17, 3:58 AM, "Matt Caswell" wrote: On 27/12/17 22:17, Salz, Rich wrote: > > Yes, exactly. The idea was we assess everything and mark ones to be > addressed for 1.1.1. Any of those should be closed by the time we release. > > That was not clear to me from the description. So you mean this? > We will review all open issues created more than two weeks before the release date, and any tagged for 1.1.1 must be closed for the release. Yes. Assuming that an outcome from "review all open issues" would be the tagging of some issues with 1.1.1. Matt _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From tjh at cryptsoft.com Thu Dec 28 21:14:57 2017 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 29 Dec 2017 07:14:57 +1000 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: <7D5A5CAF-571C-4B45-A88A-5BA24D6F86EA@akamai.com> References: <3851F646-644D-4AA8-8931-6EAD5105CC7D@akamai.com> <1b61a29b-035e-9786-c8e9-d3feb0888340@openssl.org> <20171224060933.GZ39477@kduck.kaduk.org> <20171225.121411.190562330569812696.levitte@openssl.org> <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> <7D5A5CAF-571C-4B45-A88A-5BA24D6F86EA@akamai.com> Message-ID: The original wording has unknown scope - the same issue applies - we could tag everything with 1.1.1 relevance and that would mean a whole pile of work. Without criteria to set what is in or out of the release we wouldn't be consistent in the approach - i.e. we could argue every issue either in or out based on individual criteria (assuming it applies to the code base and isn't something already fixed). I think we can have an objective timeline - but it depends entirely on getting through the classification of issues for in/out of the release - and that needs to be made clear - and that sort of distinction I think pretty much everyone will ignore. If we publish a target set of dates people should have some expectation we are aiming at those dates - and without a review of the issues, the current criteria (to me at least) doesn't make sense as we have a large unknown scope sitting in the middle of it. If we are planning to include all issues relevant (i.e. potentially all issues that actually apply to the code base in question) in the 1.1.1 release then we need to scope that first. Tim. On Fri, Dec 29, 2017 at 7:01 AM, Salz, Rich wrote: > If I?m the only one confused by the original wording, then leave it. > > On 12/28/17, 3:58 AM, "Matt Caswell" wrote: > > > > On 27/12/17 22:17, Salz, Rich wrote: > > > > Yes, exactly. The idea was we assess everything and mark ones to > be > > addressed for 1.1.1. Any of those should be closed by the time > we release. > > > > That was not clear to me from the description. So you mean this? > > We will review all open issues created more than two weeks before > the release date, and any tagged for 1.1.1 must be closed for the release. > > Yes. Assuming that an outcome from "review all open issues" would be > the > tagging of some issues with 1.1.1. > > Matt > > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Thu Dec 28 21:26:14 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 28 Dec 2017 22:26:14 +0100 Subject: [openssl-project] 1.1.1 Release timetable In-Reply-To: References: <6fa8546c-5447-c6ec-b462-87a17c4621ac@openssl.org> <88B59FCB-D639-4670-A235-7D44E184CDBB@akamai.com> <4d1916c0-7b4d-4a92-43b5-f4fed64bfa0d@openssl.org> <890CF184-3A70-47FD-BBD7-49ACC21F117D@akamai.com> <2FE96B39-A7E2-4A9C-A8D0-40312807C901@dukhovni.org> <0fa99433-ff07-dbc8-1e11-0de076760bf8@openssl.org> <7D5A5CAF-571C-4B45-A88A-5BA24D6F86EA@akamai.com> Message-ID: <20171228212614.GA8200@roeckx.be> On Fri, Dec 29, 2017 at 07:14:57AM +1000, Tim Hudson wrote: > The original wording has unknown scope - the same issue applies - we could > tag everything with 1.1.1 relevance and that would mean a whole pile of > work. > Without criteria to set what is in or out of the release we wouldn't be > consistent in the approach - i.e. we could argue every issue either in or > out based on individual criteria (assuming it applies to the code base and > isn't something already fixed). > > I think we can have an objective timeline - but it depends entirely on > getting through the classification of issues for in/out of the release - > and that needs to be made clear - and that sort of distinction I think > pretty much everyone will ignore. > If we publish a target set of dates people should have some expectation we > are aiming at those dates - and without a review of the issues, the current > criteria (to me at least) doesn't make sense as we have a large unknown > scope sitting in the middle of it. > > If we are planning to include all issues relevant (i.e. potentially all > issues that actually apply to the code base in question) in the 1.1.1 > release then we need to scope that first. Maybe what is most relevant are regressions compared to previous versions? Kurt