[openssl-project] GitHub milestone for 1.1.1

Mon Mar 19 11:52:11 UTC 2018

In message <7aa44215-febf-73d2-3d0f-12f99b44b8aa at openssl.org> on Mon, 19 Mar 2018 11:14:27 +0000, Matt Caswell <matt at openssl.org> 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 <matt at openssl.org> 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> >>> <https://github.com/openssl/openssl/milestone/9> 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 past the beta freeze?
matt> >>
matt> >> Mostly, I think what remains are bugs and not features. If there are
matt> >> features then no one cared enough about them to push them forward to
matt> >> get
matt> >> into 1.1.1 and so we should reclassify them with a post-1.1.1
matt> >> milestone.
matt> >> In some exceptional cases, if someone can make a good enough case, we
matt> >> might consider merging them during the beta - but that might take an
matt> >> omc
matt> >> vote, so the case would have to be very strong.
matt> >>
matt> >> We have always treated missing documentation as a bug so I don't see a
matt> >> problem there.
matt> >>
matt> >> Matt
matt> >>
matt> >>>
matt> >>> Regards,
matt> >>> Matthias
matt> >>>
matt> >>> --
matt> >>> We have defined the following release criteria for 1.1.1:
matt> >>>
matt> >>> All open github issues/PRs older than 2 weeks at the time of release
matt> >> to
matt> >>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
matt> >> milestone
matt> >>> to be closed (see below)
matt> >>> Clean builds in Travis and Appveyor for two days
matt> >>> run-checker.sh to be showing as clean 2 days before release
matt> >>> No open Coverity issues (not flagged as "False Positive" or "Ignore")
matt> >>> TLSv1.3 RFC published
matt> >>> https://www.openssl.org/policies/releasestrat.html
matt> >>>
matt> >>>
matt> >>> _______________________________________________
matt> >>> openssl-project mailing list
matt> >>> openssl-project at openssl.org
matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> >>>
matt> >> _______________________________________________
matt> >> openssl-project mailing list
matt> >> openssl-project at openssl.org
matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > 
matt> _______________________________________________
matt> openssl-project mailing list
matt> openssl-project at openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 