Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

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.

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.

Note: this affects VMS only, at least re make variables.

Cheers
Richard

(*) 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:

 /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")

The same goes for include paths, similarly collected in the qualifier /INCLUDE


Matt Caswell  skrev: (19 mars 2018 10:12:06 CET)
>
>
>On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
>> Hi,
>> 
>> in view of the upcoming beta release and the release strategy (see
>> below) it is a little bit disturbing that our GitHub milestone for
>1.1.1
>>  shows only 30%
>> completion. How are we going to deal with this?
>
>Up until now, understandably, people have been focusing on getting the
>required features in. My expectation is that, once we're past the beta
>release and new features are no longer allowed for 1.1.1, focus will
>shift to closing off as many of the open issues/PRs as possible.
>
>> Shouldn't the PR's and
>> issues be examined and categorized into bugs and features? The former
>> could still be merged during beta, but what happens to the latter?
>What
>> is with outstanding documentation (e.g. #5461, #5629), will it be
>> treated like a bugfix and be mergeable past the beta freeze?
>
>Mostly, I think what remains are bugs and not features. If there are
>features then no one cared enough about them to push them forward to
>get
>into 1.1.1 and so we should reclassify them with a post-1.1.1
>milestone.
>In some exceptional cases, if someone can make a good enough case, we
>might consider merging them during the beta - but that might take an
>omc
>vote, so the case would have to be very strong.
>
>We have always treated missing documentation as a bug so I don't see a
>problem there.
>
>Matt
>
>> 
>> Regards,
>> Matthias
>> 
>> --
>> We have defined the following release criteria for 1.1.1:
>> 
>> 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
>> https://www.openssl.org/policies/releasestrat.html
>> 
>> 
>> ___
>> openssl-project mailing list
>> openssl-project@openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>> 
>___
>openssl-project mailing list
>openssl-project@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Code freeze later today

[Matt Caswell]

Just a reminder that beta1 is scheduled for release tomorrow so, in
preparation for that, I will be freezing the repo later today. Of course
this really means feature freeze as well since this will be your last
opportunity to push features before the beta release. So if there is
anything still outstanding, please get it pushed asap!

Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Matt Caswell]

On 19/03/18 10:58, Richard Levitte wrote:
> 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.
> 
> 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.

Well what is a "fix" has always been a bit of a grey area.

Does the proposed change offer new capabilities to the user that they
didn't have before?

If the answer is "yes" that tends to indicate a feature.

Does the proposed change fix existing capabilities so that they work as
originally intended?

An answer of "yes" to that tends to indicate a fix.

It becomes more difficult when something is a a general clean up or
optimisation of existing code. In which case nothing is fixed, but it
also doesn't provide new capabilities to the user either.

In the past, sometimes we have let this sort of thing through and
sometimes not. I suppose it comes down to the scale of the change and
risk associated with it. For example the WPACKET refactor didn't make it
into 1.1.0. It wasn't a new feature and was a clean up of existing code.
We didn't backport it because the scale of the change and risk
associated with it is too great. On the other hand if a change is much
more localised with a low level of risk then we might allow it. Probably
we make these decisions on a case by case basis, unless someone can
think of some better "rules".

I haven't got a good understanding of the particular change you are
proposing to be able to say where in all of this that one fits.

Matt

> 
> Note: this affects VMS only, at least re make variables.
> 
> Cheers
> Richard
> 
> (*) 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:
> 
>  /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
> 
> The same goes for include paths, similarly collected in the qualifier /INCLUDE
> 
> 
> Matt Caswell  skrev: (19 mars 2018 10:12:06 CET)
>>
>>
>> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
>>> Hi,
>>>
>>> in view of the upcoming beta release and the release strategy (see
>>> below) it is a little bit disturbing that our GitHub milestone for
>> 1.1.1
>>>  shows only 30%
>>> completion. How are we going to deal with this?
>>
>> Up until now, understandably, people have been focusing on getting the
>> required features in. My expectation is that, once we're past the beta
>> release and new features are no longer allowed for 1.1.1, focus will
>> shift to closing off as many of the open issues/PRs as possible.
>>
>>> Shouldn't the PR's and
>>> issues be examined and categorized into bugs and features? The former
>>> could still be merged during beta, but what happens to the latter?
>> What
>>> is with outstanding documentation (e.g. #5461, #5629), will it be
>>> treated like a bugfix and be mergeable past the beta freeze?
>>
>> Mostly, I think what remains are bugs and not features. If there are
>> features then no one cared enough about them to push them forward to
>> get
>> into 1.1.1 and so we should reclassify them with a post-1.1.1
>> milestone.
>> In some exceptional cases, if someone can make a good enough case, we
>> might consider merging them during the beta - but that might take an
>> omc
>> vote, so the case would have to be very strong.
>>
>> We have always treated missing documentation as a bug so I don't see a
>> problem there.
>>
>> Matt
>>
>>>
>>> Regards,
>>> Matthias
>>>
>>> --
>>> We have defined the following release criteria for 1.1.1:
>>>
>>> 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
>>> https://www.openssl.org/policies/releasestrat.html
>>>
>>>
>>> ___
>>> openssl-project mailing list
>>> openssl-project@openssl.org
>>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>>
>> ___
>> openssl-project mailing list
>> openssl-project@openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

In message <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon, 19 Mar 
2018 11:14:27 +, Matt Caswell  said:

matt> 
matt> 
matt> On 19/03/18 10:58, Richard Levitte wrote:
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> > 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> Well what is a "fix" has always been a bit of a grey area.
matt> 
matt> Does the proposed change offer new capabilities to the user that they
matt> didn't have before?
matt> 
matt> If the answer is "yes" that tends to indicate a feature.

So I'll answer "yes and no", with a bit of explanation.

The whole thing with supporting the use of "make variables" with
Configure in GNU autoconf style is a new feature, but that's already
in, so I count that is already existing capabilities re the beta
release.

Being able to define macros and include directories via CPPFLAGS is
thusly already available...  except that for VMS users, we have
CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax.

So phrased "being able to define extra C macros and include
directories via 'make variables' when configuring", this is not a new
capability.  However, phrased "being able to define extra C macros and
include directories via CPPFLAGS in when configuring", this could be
viewed as a new capability.

matt> Does the proposed change fix existing capabilities so that they
matt> work as originally intended?
matt> 
matt> An answer of "yes" to that tends to indicate a fix.

Well, I could say "yes" if the original intent is phrased "CPPFLAGS
is used for all C preprocessor flags"...  which is the usual intent,
at least on platforms with Unix style flags, and considering CPPFLAGS
has originated on Unix as far as I know, ...

matt> I haven't got a good understanding of the particular change you
matt> are proposing to be able to say where in all of this that one
matt> fits.

The idea I have would affect Configurations/descrip.mms.tmpl more or
less entirely, and would be to parse $config{CPPFLAGS}, extract and
put aside any macro definitions and include directory specs and put
back the rest of what was parsed back in $config{CPPFLAGS}, and use
the extracted macro definitions and include directory specs further
on, in these lines:

DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) -}
INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -}

What happens in practice is that $config{CPPDEFINES} and
$config{CPPINCLUDES} would stop existing, and template internal
variables would take their place in those two lines.

And of course, all traces of CPPDEFINES and CPPINCLUDES would be
removed anywhere else...  that's mostly config and Configure.

Cheers,
Richard

matt> 
matt> Matt
matt> 
matt> > 
matt> > Note: this affects VMS only, at least re make variables.
matt> > 
matt> > Cheers
matt> > Richard
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> >  /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
matt> > 
matt> > The same goes for include paths, similarly collected in the qualifier 
/INCLUDE
matt> > 
matt> > 
matt> > Matt Caswell  skrev: (19 mars 2018 10:12:06 CET)
matt> >>
matt> >>
matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
matt> >>> Hi,
matt> >>>
matt> >>> in view of the upcoming beta release and the release strategy (see
matt> >>> below) it is a little bit disturbing that our GitHub milestone for
matt> >> 1.1.1
matt> >>>  shows only 30%
matt> >>> completion. How are we going to deal with this?
matt> >>
matt> >> Up until now, understandably, people have been focusing on getting the
matt> >> required features in. My expectation is that, once we're past the beta
matt> >> release and new features are no longer allowed for 1.1.1, focus will
matt> >> shift to closing off as many of the open issues/PRs as possible.
matt> >>
matt> >>> Shouldn't the PR's and
matt> >>> issues be examined and categorized into bugs and features? The former
matt> >>> could still be merged during beta, but what happens to the latter?
matt> >> What
matt> >>> is with outstanding documentation (e.g. #5461, #5629), will it be
matt> >>> treated like a bugfix and be mergeable 

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

In message <001364a7-e3c5-4e2b-8f0b-6ed1a041f...@akamai.com> on Mon, 19 Mar 
2018 12:27:19 +, "Salz, Rich"  said:

rsalz> I would consider it a bug-fix FWIW.
rsalz> 
rsalz> I thought we extended the deadline so that we could review more
rsalz> third-party PR's.I'm still waiting on an e_os/Microsoft
rsalz> cleanup, but getting community stuff in is more important.

I did a quick sweep last week through those that were marked with
milestone 1.1.1 or no milestone at all, and found most to be of the
category "fix"...  there were a few that I was wondering about, and I
hope I at least pinged them.

There's one I know where we need to make a judgement call.  PR 4793
"(WIP) An implementation of the Chinese SM2 ECC".  I intended to have
a look last week, but didn't.  That one's a lot for me to take in, and
ECC is most decidly not one of my fortes...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Matt Caswell]

This is definitely in the grey area, but I tend to think it is more
towards the "fix" side than the "feature" side. Also the risk is
significantly mitigated by it only impacting VMS.

Matt


On 19/03/18 11:52, Richard Levitte wrote:
> In message <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon, 19 Mar 
> 2018 11:14:27 +, Matt Caswell  said:
> 
> matt> 
> matt> 
> matt> On 19/03/18 10:58, Richard Levitte wrote:
> 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> > 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> Well what is a "fix" has always been a bit of a grey area.
> matt> 
> matt> Does the proposed change offer new capabilities to the user that they
> matt> didn't have before?
> matt> 
> matt> If the answer is "yes" that tends to indicate a feature.
> 
> So I'll answer "yes and no", with a bit of explanation.
> 
> The whole thing with supporting the use of "make variables" with
> Configure in GNU autoconf style is a new feature, but that's already
> in, so I count that is already existing capabilities re the beta
> release.
> 
> Being able to define macros and include directories via CPPFLAGS is
> thusly already available...  except that for VMS users, we have
> CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax.
> 
> So phrased "being able to define extra C macros and include
> directories via 'make variables' when configuring", this is not a new
> capability.  However, phrased "being able to define extra C macros and
> include directories via CPPFLAGS in when configuring", this could be
> viewed as a new capability.
> 
> matt> Does the proposed change fix existing capabilities so that they
> matt> work as originally intended?
> matt> 
> matt> An answer of "yes" to that tends to indicate a fix.
> 
> Well, I could say "yes" if the original intent is phrased "CPPFLAGS
> is used for all C preprocessor flags"...  which is the usual intent,
> at least on platforms with Unix style flags, and considering CPPFLAGS
> has originated on Unix as far as I know, ...
> 
> matt> I haven't got a good understanding of the particular change you
> matt> are proposing to be able to say where in all of this that one
> matt> fits.
> 
> The idea I have would affect Configurations/descrip.mms.tmpl more or
> less entirely, and would be to parse $config{CPPFLAGS}, extract and
> put aside any macro definitions and include directory specs and put
> back the rest of what was parsed back in $config{CPPFLAGS}, and use
> the extracted macro definitions and include directory specs further
> on, in these lines:
> 
> DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) 
> -}
> INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -}
> 
> What happens in practice is that $config{CPPDEFINES} and
> $config{CPPINCLUDES} would stop existing, and template internal
> variables would take their place in those two lines.
> 
> And of course, all traces of CPPDEFINES and CPPINCLUDES would be
> removed anywhere else...  that's mostly config and Configure.
> 
> Cheers,
> Richard
> 
> matt> 
> matt> Matt
> matt> 
> matt> > 
> matt> > Note: this affects VMS only, at least re make variables.
> matt> > 
> matt> > Cheers
> matt> > Richard
> 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> >  /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
> matt> > 
> matt> > The same goes for include paths, similarly collected in the qualifier 
> /INCLUDE
> matt> > 
> matt> > 
> matt> > Matt Caswell  skrev: (19 mars 2018 10:12:06 CET)
> matt> >>
> matt> >>
> matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
> matt> >>> Hi,
> matt> >>>
> matt> >>> in view of the upcoming beta release and the release strategy (see
> matt> >>> below) it is a little bit disturbing that our GitHub milestone for
> matt> >> 1.1.1
> matt> >>>  shows only 30%
> matt> >>> completion. How are we going to deal with this?
> matt> >>
> matt> >> Up until now, understandably, people have been focusing on getting 
> the
> matt> >> required features in. My expectation is that, once we're past the 
> beta
> matt> >> release and new 

Re: [openssl-project] GitHub milestone for 1.1.1

[Tim Hudson]

I too see this in the "bug fix" area - although you can make a reasonable
counter argument (but I don't see a lot of point in doing so).
Improving the build environment is a good thing IMHO ...

Tim.


On Mon, Mar 19, 2018 at 10:27 PM, Salz, Rich  wrote:

> I would consider it a bug-fix FWIW.
>
> I thought we extended the deadline so that we could review more
> third-party PR's.I'm still waiting on an e_os/Microsoft cleanup, but
> getting community stuff in is more important.
>
>
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] GitHub milestone for 1.1.1

[Dr. Matthias St. Pierre]

Hi,

in view of the upcoming beta release and the release strategy (see
below) it is a little bit disturbing that our GitHub milestone for 1.1.1
 shows only 30%
completion. How are we going to deal with this? Shouldn't the PR's and
issues be examined and categorized into bugs and features? The former
could still be merged during beta, but what happens to the latter? What
is with outstanding documentation (e.g. #5461, #5629), will it be
treated like a bugfix and be mergeable past the beta freeze?

Regards,
Matthias

--
We have defined the following release criteria for 1.1.1:

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
https://www.openssl.org/policies/releasestrat.html


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Matt Caswell]

On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
> Hi,
> 
> in view of the upcoming beta release and the release strategy (see
> below) it is a little bit disturbing that our GitHub milestone for 1.1.1
>  shows only 30%
> completion. How are we going to deal with this?

Up until now, understandably, people have been focusing on getting the
required features in. My expectation is that, once we're past the beta
release and new features are no longer allowed for 1.1.1, focus will
shift to closing off as many of the open issues/PRs as possible.

> Shouldn't the PR's and
> issues be examined and categorized into bugs and features? The former
> could still be merged during beta, but what happens to the latter? What
> is with outstanding documentation (e.g. #5461, #5629), will it be
> treated like a bugfix and be mergeable past the beta freeze?

Mostly, I think what remains are bugs and not features. If there are
features then no one cared enough about them to push them forward to get
into 1.1.1 and so we should reclassify them with a post-1.1.1 milestone.
In some exceptional cases, if someone can make a good enough case, we
might consider merging them during the beta - but that might take an omc
vote, so the case would have to be very strong.

We have always treated missing documentation as a bug so I don't see a
problem there.

Matt

> 
> Regards,
> Matthias
> 
> --
> We have defined the following release criteria for 1.1.1:
> 
> 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
> https://www.openssl.org/policies/releasestrat.html
> 
> 
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

Ok.  I see it the same way, and indications are that others would
agree as well...

In message  on Mon, 19 Mar 
2018 11:56:23 +, Matt Caswell  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 <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon, 
19 Mar 2018 11:14:27 +, Matt Caswell  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

Re: [openssl-project] GitHub milestone for 1.1.1

[Salz, Rich]

Yes, SM2 ECC is a big one that seems to have fallen thru the cracks. And 4848. 
That is *very* unfortunate.

Instead time and energy went to FIXING Android, configure command-line, and 
various no-XXX builds. 

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

In message <97cff4a5-de0e-4d17-8a07-242961d6f...@akamai.com> on Mon, 19 Mar 
2018 12:47:05 +, "Salz, Rich"  said:

rsalz> Yes, SM2 ECC is a big one that seems to have fallen thru the cracks. And 
4848. That is *very* unfortunate.
rsalz> 
rsalz> Instead time and energy went to FIXING Android, configure command-line, 
and various no-XXX builds. 

I just looked through the SM2 PR and apart from a need for rebase
(which is all about 'make update', so quite frankly, I think that can
fall on whoever merges...  I'm just tried, it took me 5 minutes).

I'm willing to approve it as it stands.  Everything that stung my eye
earlier has been changed to something a lot better.  The only thing
that still stings my eye is those public SM2 functions, but I would
see their removal as a fix, so...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Anything else to go in before I call the freeze?

[Bernd Edlinger]

OK, I freezed the repository for you.

On 03/19/18 19:25, Matt Caswell wrote:
> Please can someone freeze the repo for me:
> 
> $ ssh openssl-...@git.openssl.org freeze openssl matt
> 
> I will still take #5677 "Fix no-sm3 (and no-sm2)" after the freeze. Also
> if anyone can come up with a fix for the failing master in Travis that
> would be good.
> 
> Matt
> 
> 
> On 19/03/18 16:48, Matt Caswell wrote:
>> BTW please review #5673. I'd like a clean run from run-checker for the
>> release tomorrow.
>>
>> Matt
>>
>> On 19/03/18 16:33, Matt Caswell wrote:
>>> Let me know asap...
>>>
>>>
>>> Matt
>>> ___
>>> openssl-project mailing list
>>> openssl-project@openssl.org
>>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>>
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Anything else to go in before I call the freeze?

[Matt Caswell]

Please can someone freeze the repo for me:

$ ssh openssl-...@git.openssl.org freeze openssl matt

I will still take #5677 "Fix no-sm3 (and no-sm2)" after the freeze. Also
if anyone can come up with a fix for the failing master in Travis that
would be good.

Matt


On 19/03/18 16:48, Matt Caswell wrote:
> BTW please review #5673. I'd like a clean run from run-checker for the
> release tomorrow.
> 
> Matt
> 
> On 19/03/18 16:33, Matt Caswell wrote:
>> Let me know asap...
>>
>>
>> Matt
>> ___
>> openssl-project mailing list
>> openssl-project@openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Anything else to go in before I call the freeze?

[Matt Caswell]

Let me know asap...


Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Anything else to go in before I call the freeze?

[Richard Levitte]

In message <1ab966c8-02d4-cf1f-504a-a54999a7c...@openssl.org> on Mon, 19 Mar 
2018 16:33:57 +, Matt Caswell  said:

matt> Let me know asap...

#5662 #5663

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Anything else to go in before I call the freeze?

[Matt Caswell]

BTW please review #5673. I'd like a clean run from run-checker for the
release tomorrow.

Matt

On 19/03/18 16:33, Matt Caswell wrote:
> Let me know asap...
> 
> 
> Matt
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project