[openssl-project] GitHub milestone for 1.1.1

Mon Mar 19 11:56:23 UTC 2018

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-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> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 