[openssl-project] GitHub milestone for 1.1.1

Mon Mar 19 11:59:20 UTC 2018

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

In message <a55791e9-83d8-199d-9d8b-c6157e16452c at openssl.org> on Mon, 19 Mar 2018 11:56:23 +0000, Matt Caswell <matt at openssl.org> 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-12f99b44b8aa at openssl.org> on Mon, 19 Mar 2018 11:14:27 +0000, Matt Caswell <matt at openssl.org> 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 <matt at openssl.org> 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> >>> openssl-project at openssl.org
matt> > matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > matt> >>>
matt> > matt> >> _______________________________________________
matt> > matt> >> openssl-project mailing list
matt> > matt> >> openssl-project at openssl.org
matt> > matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > matt> > 
matt> > matt> _______________________________________________
matt> > matt> openssl-project mailing list
matt> > matt> openssl-project at openssl.org
matt> > matt> https://mta.openssl.org/mailman/listinfo/openssl-project
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> 