Ok. I see it the same way, and indications are that others would agree as well...
In message <[email protected]> on Mon, 19 Mar 2018 11:56:23 +0000, Matt Caswell <[email protected]> said: matt> This is definitely in the grey area, but I tend to think it is more matt> towards the "fix" side than the "feature" side. Also the risk is matt> significantly mitigated by it only impacting VMS. matt> matt> Matt matt> matt> matt> On 19/03/18 11:52, Richard Levitte wrote: matt> > In message <[email protected]> on Mon, 19 Mar 2018 11:14:27 +0000, Matt Caswell <[email protected]> said: matt> > matt> > matt> matt> > matt> matt> > matt> On 19/03/18 10:58, Richard Levitte wrote: matt> > matt> > Andy has indicated that the rather special construction to get command line C macro definitions and include paths specs collected in one place (*) is perhaps too special and could be handle by parsing CPPFLAGS and extra multiple definitions to get them collected in one spot. matt> > matt> > matt> > matt> > I have some ideas on how to do that, but wonder if that would be considered a new feature with regards to the beta release (we can stop talking now in that case) or if this would be considered a fix. That will decide if it's even worth an effort. matt> > matt> matt> > matt> Well what is a "fix" has always been a bit of a grey area. matt> > matt> matt> > matt> Does the proposed change offer new capabilities to the user that they matt> > matt> didn't have before? matt> > matt> matt> > matt> If the answer is "yes" that tends to indicate a feature. matt> > matt> > So I'll answer "yes and no", with a bit of explanation. matt> > matt> > The whole thing with supporting the use of "make variables" with matt> > Configure in GNU autoconf style is a new feature, but that's already matt> > in, so I count that is already existing capabilities re the beta matt> > release. matt> > matt> > Being able to define macros and include directories via CPPFLAGS is matt> > thusly already available... except that for VMS users, we have matt> > CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax. matt> > matt> > So phrased "being able to define extra C macros and include matt> > directories via 'make variables' when configuring", this is not a new matt> > capability. However, phrased "being able to define extra C macros and matt> > include directories via CPPFLAGS in when configuring", this could be matt> > viewed as a new capability. matt> > matt> > matt> Does the proposed change fix existing capabilities so that they matt> > matt> work as originally intended? matt> > matt> matt> > matt> An answer of "yes" to that tends to indicate a fix. matt> > matt> > Well, I could say "yes" if the original intent is phrased "CPPFLAGS matt> > is used for all C preprocessor flags"... which is the usual intent, matt> > at least on platforms with Unix style flags, and considering CPPFLAGS matt> > has originated on Unix as far as I know, ... matt> > matt> > matt> I haven't got a good understanding of the particular change you matt> > matt> are proposing to be able to say where in all of this that one matt> > matt> fits. matt> > matt> > The idea I have would affect Configurations/descrip.mms.tmpl more or matt> > less entirely, and would be to parse $config{CPPFLAGS}, extract and matt> > put aside any macro definitions and include directory specs and put matt> > back the rest of what was parsed back in $config{CPPFLAGS}, and use matt> > the extracted macro definitions and include directory specs further matt> > on, in these lines: matt> > matt> > DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) -} matt> > INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -} matt> > matt> > What happens in practice is that $config{CPPDEFINES} and matt> > $config{CPPINCLUDES} would stop existing, and template internal matt> > variables would take their place in those two lines. matt> > matt> > And of course, all traces of CPPDEFINES and CPPINCLUDES would be matt> > removed anywhere else... that's mostly config and Configure. matt> > matt> > Cheers, matt> > Richard matt> > matt> > matt> matt> > matt> Matt matt> > matt> matt> > matt> > matt> > matt> > Note: this affects VMS only, at least re make variables. matt> > matt> > matt> > matt> > Cheers matt> > matt> > Richard matt> > matt> > matt> > matt> > (*) Unix and windows handles those with -D and -I flags that can be spread out all over the command line. VMS command lines work a bit differently, and the C compiler complies with that standard, so *all* macros must be collected in *one* qualifiers (VMS terminology where the Unix guy would say "flag" or possibly "option"), like this: matt> > matt> > matt> > matt> > /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar") matt> > matt> > matt> > matt> > The same goes for include paths, similarly collected in the qualifier /INCLUDE matt> > matt> > matt> > matt> > matt> > matt> > Matt Caswell <[email protected]> skrev: (19 mars 2018 10:12:06 CET) matt> > matt> >> matt> > matt> >> matt> > matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote: matt> > matt> >>> Hi, matt> > matt> >>> matt> > matt> >>> in view of the upcoming beta release and the release strategy (see matt> > matt> >>> below) it is a little bit disturbing that our GitHub milestone for matt> > matt> >> 1.1.1 matt> > matt> >>> <https://github.com/openssl/openssl/milestone/9> shows only 30% matt> > matt> >>> completion. How are we going to deal with this? matt> > matt> >> matt> > matt> >> Up until now, understandably, people have been focusing on getting the matt> > matt> >> required features in. My expectation is that, once we're past the beta matt> > matt> >> release and new features are no longer allowed for 1.1.1, focus will matt> > matt> >> shift to closing off as many of the open issues/PRs as possible. matt> > matt> >> matt> > matt> >>> Shouldn't the PR's and matt> > matt> >>> issues be examined and categorized into bugs and features? The former matt> > matt> >>> could still be merged during beta, but what happens to the latter? matt> > matt> >> What matt> > matt> >>> is with outstanding documentation (e.g. #5461, #5629), will it be matt> > matt> >>> treated like a bugfix and be mergeable past the beta freeze? matt> > matt> >> matt> > matt> >> Mostly, I think what remains are bugs and not features. If there are matt> > matt> >> features then no one cared enough about them to push them forward to matt> > matt> >> get matt> > matt> >> into 1.1.1 and so we should reclassify them with a post-1.1.1 matt> > matt> >> milestone. matt> > matt> >> In some exceptional cases, if someone can make a good enough case, we matt> > matt> >> might consider merging them during the beta - but that might take an matt> > matt> >> omc matt> > matt> >> vote, so the case would have to be very strong. matt> > matt> >> matt> > matt> >> We have always treated missing documentation as a bug so I don't see a matt> > matt> >> problem there. matt> > matt> >> matt> > matt> >> Matt matt> > matt> >> matt> > matt> >>> matt> > matt> >>> Regards, matt> > matt> >>> Matthias matt> > matt> >>> matt> > matt> >>> -- matt> > matt> >>> We have defined the following release criteria for 1.1.1: matt> > matt> >>> matt> > matt> >>> All open github issues/PRs older than 2 weeks at the time of release matt> > matt> >> to matt> > matt> >>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 matt> > matt> >> milestone matt> > matt> >>> to be closed (see below) matt> > matt> >>> Clean builds in Travis and Appveyor for two days matt> > matt> >>> run-checker.sh to be showing as clean 2 days before release matt> > matt> >>> No open Coverity issues (not flagged as "False Positive" or "Ignore") matt> > matt> >>> TLSv1.3 RFC published matt> > matt> >>> https://www.openssl.org/policies/releasestrat.html matt> > matt> >>> matt> > matt> >>> matt> > matt> >>> _______________________________________________ matt> > matt> >>> openssl-project mailing list matt> > matt> >>> [email protected] matt> > matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project matt> > matt> >>> matt> > matt> >> _______________________________________________ matt> > matt> >> openssl-project mailing list matt> > matt> >> [email protected] matt> > matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project matt> > matt> > matt> > matt> _______________________________________________ matt> > matt> openssl-project mailing list matt> > matt> [email protected] matt> > matt> https://mta.openssl.org/mailman/listinfo/openssl-project matt> > matt> matt> > _______________________________________________ matt> > openssl-project mailing list matt> > [email protected] matt> > https://mta.openssl.org/mailman/listinfo/openssl-project matt> > matt> _______________________________________________ matt> openssl-project mailing list matt> [email protected] matt> https://mta.openssl.org/mailman/listinfo/openssl-project matt> _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
