[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 <matt at openssl.org> 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
>>> <https://github.com/openssl/openssl/milestone/9> 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 at openssl.org
>>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>>
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>