6:11 a.m.
Planning to post this to -announce soon, any comments?
Just a reminder to everyone: the Project has a long-standing policy of
doing active development on only one release version at a time. To
allow time for migrations we provide some overlap from one release
version to the next. E.g., while 2.5 is active we will still provide
critical bugfixes for 2.4. Since 2.4 has been around for something
like 14 years now people may have forgotten this policy.
This is a heads up that with 2.6 due for release in September, all
updates to 2.4 will cease at that time. Likewise, when 2.7 is released
next year all updates to 2.5 will cease.
Also for clarity: We consider "Critical" bugs to include security
flaws resulting in unauthorized data disclosure, or unauthorized
remote code execution. We do not consider assert() failures or crashes
resulting only in Denial of Service as security flaws.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:37 a.m.
On Fri, Aug 06, 2021 at 02:11:12PM +0100, Howard Chu wrote:
Planning to post this to -announce soon, any comments?
Just a reminder to everyone: the Project has a long-standing policy of
doing active development on only one release version at a time. To
allow time for migrations we provide some overlap from one release
version to the next. E.g., while 2.5 is active we will still provide
critical bugfixes for 2.4. Since 2.4 has been around for something
like 14 years now people may have forgotten this policy.
This is a heads up that with 2.6 due for release in September, all
updates to 2.4 will cease at that time. Likewise, when 2.7 is released
next year all updates to 2.5 will cease.
Also for clarity: We consider "Critical" bugs to include security
flaws resulting in unauthorized data disclosure, or unauthorized
remote code execution. We do not consider assert() failures or crashes
resulting only in Denial of Service as security flaws.
Sounds good and to the point.
Thanks,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
1:17 p.m.
--On Friday, August 6, 2021 3:11 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
Planning to post this to -announce soon, any comments?
Just a reminder to everyone: the Project has a long-standing policy of
doing active development on only one release version at a time. To
allow time for migrations we provide some overlap from one release
version to the next. E.g., while 2.5 is active we will still provide
critical bugfixes for 2.4. Since 2.4 has been around for something
like 14 years now people may have forgotten this policy.
This is a heads up that with 2.6 due for release in September, all
updates to 2.4 will cease at that time. Likewise, when 2.7 is released
next year all updates to 2.5 will cease.
Also for clarity: We consider "Critical" bugs to include security
flaws resulting in unauthorized data disclosure, or unauthorized
remote code execution. We do not consider assert() failures or crashes
resulting only in Denial of Service as security flaws.
That's fine as a general statement, but what we need is an explicit
*documented* policy. Likely under "Release Documents" here:
<https://www.openldap.org/software/>
Also, I'd like to see explicit terms here. I.e., 2.4 is now in
maintenance, which means only critical fixes are applied. 2.5 is active,
which means it has an active release schedule and is open for general bug
fixes. 2.6 is in development which means that is where all new feature
development and distruptive changes are occurring.
As a part of that explicit policy and terminology, we need to provide some
sort of time table on when a release moves from active to maintenance.
Clearly it would not have been fair to move 2.4 to maintenance the moment
2.5 released (for example we've done one non-security based release of 2.4
since 2.5 came out). At this point, I think it's fair for 2.4 to be in
maintenance and 2.5 to be the sole active release, however it would
generally be unfair to mark 2.5 maintenance the moment 2.6 releases.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4:31 a.m.
Quanah Gibson-Mount wrote:
--On Friday, August 6, 2021 3:11 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
> Planning to post this to -announce soon, any comments?
>
>
> Just a reminder to everyone: the Project has a long-standing policy of
> doing active development on only one release version at a time. To
> allow time for migrations we provide some overlap from one release
> version to the next. E.g., while 2.5 is active we will still provide
> critical bugfixes for 2.4. Since 2.4 has been around for something
> like 14 years now people may have forgotten this policy.
>
> This is a heads up that with 2.6 due for release in September, all
> updates to 2.4 will cease at that time. Likewise, when 2.7 is released
> next year all updates to 2.5 will cease.
>
> Also for clarity: We consider "Critical" bugs to include security
> flaws resulting in unauthorized data disclosure, or unauthorized
> remote code execution. We do not consider assert() failures or crashes
> resulting only in Denial of Service as security flaws.
That's fine as a general statement, but what we need is an explicit *documented*
policy. Likely under "Release Documents" here:
<https://www.openldap.org/software/>
Sounds like you should open a ticket against the website then.
Also, I'd like to see explicit terms here. I.e., 2.4 is now in maintenance, which
means only critical fixes are applied. 2.5 is active, which means it has an
active release schedule and is open for general bug fixes. 2.6 is in development which
means that is where all new feature development and distruptive changes
are occurring.
As a part of that explicit policy and terminology, we need to provide some sort of time
table on when a release moves from active to maintenance. Clearly it
would not have been fair to move 2.4 to maintenance the moment 2.5 released (for example
we've done one non-security based release of 2.4 since 2.5 came out).
It would have been entirely fair. 2.4 has been around for 14 years and we had declared a
feature freeze on
it long ago already. Doing a non-security based 2.4 release after 2.5 was released was an
anomaly, one nobody
should rely on happening.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:31 p.m.
--On Saturday, August 7, 2021 1:31 PM +0100 Howard Chu <hyc(a)symas.com>
wrote:
>> Also for clarity: We consider "Critical" bugs to
include security
>> flaws resulting in unauthorized data disclosure, or unauthorized
>> remote code execution. We do not consider assert() failures or crashes
>> resulting only in Denial of Service as security flaws.
>
> That's fine as a general statement, but what we need is an explicit
> *documented* policy. Likely under "Release Documents" here:
> <https://www.openldap.org/software/>
Sounds like you should open a ticket against the website then.
Once we have a clear, concise well formed policy I'll do that.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6:21 p.m.
Quanah Gibson-Mount wrote:
--On Saturday, August 7, 2021 1:31 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
>>> Also for clarity: We consider "Critical" bugs to include security
>>> flaws resulting in unauthorized data disclosure, or unauthorized
>>> remote code execution. We do not consider assert() failures or crashes
>>> resulting only in Denial of Service as security flaws.
>>
>> That's fine as a general statement, but what we need is an explicit
>> *documented* policy. Likely under "Release Documents" here:
>> <https://www.openldap.org/software/>
>
> Sounds like you should open a ticket against the website then.
Once we have a clear, concise well formed policy I'll do that.
That's backwards. The ticket has to exist before anyone writes a patch/MR for it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:03 p.m.
--On Sunday, August 8, 2021 3:21 AM +0100 Howard Chu <hyc(a)symas.com> wrote:
Quanah Gibson-Mount wrote:
>
>
> --On Saturday, August 7, 2021 1:31 PM +0100 Howard Chu <hyc(a)symas.com>
> wrote:
>
>>>> Also for clarity: We consider "Critical" bugs to include
security
>>>> flaws resulting in unauthorized data disclosure, or unauthorized
>>>> remote code execution. We do not consider assert() failures or crashes
>>>> resulting only in Denial of Service as security flaws.
>>>
>>> That's fine as a general statement, but what we need is an explicit
>>> *documented* policy. Likely under "Release Documents" here:
>>> <https://www.openldap.org/software/>
>>
>> Sounds like you should open a ticket against the website then.
>
> Once we have a clear, concise well formed policy I'll do that.
That's backwards. The ticket has to exist before anyone writes a patch/MR
for it.
As a project, we need to decide on a policy. Once we decide on what that
policy is, we can document it. IMHO this list is the best place to have
that discussion.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3:41 a.m.
Quanah Gibson-Mount wrote:
--On Sunday, August 8, 2021 3:21 AM +0100 Howard Chu <hyc(a)symas.com> wrote:
> Quanah Gibson-Mount wrote:
>>
>>
>> --On Saturday, August 7, 2021 1:31 PM +0100 Howard Chu <hyc(a)symas.com>
>> wrote:
>>
>>>>> Also for clarity: We consider "Critical" bugs to include
security
>>>>> flaws resulting in unauthorized data disclosure, or unauthorized
>>>>> remote code execution. We do not consider assert() failures or
crashes
>>>>> resulting only in Denial of Service as security flaws.
>>>>
>>>> That's fine as a general statement, but what we need is an explicit
>>>> *documented* policy. Likely under "Release Documents" here:
>>>> <https://www.openldap.org/software/>
>>>
>>> Sounds like you should open a ticket against the website then.
>>
>> Once we have a clear, concise well formed policy I'll do that.
>
> That's backwards. The ticket has to exist before anyone writes a patch/MR
> for it.
As a project, we need to decide on a policy. Once we decide on what that policy is, we
can document it. IMHO this list is the best place to have that discussion.
Any proposed change should to the website be requested in a ticket.
Proposed drafts should be in a merge request that can be iterated on with review
comments.
All this nitpicking over *process* is wasting time. What's important at the moment
is to get the announcement out that 2.4 is ending, while it can still be considered
"advance notice".
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:03 p.m.
--On Sunday, August 8, 2021 12:41 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
All this nitpicking over *process* is wasting time.
It's not nitpicking, it's trying to establish something well written and
concise. Clearly all that you feel is relevant is what matters.
As an aside, here's an example of a well written release policy that
clearly explains not just what the support windows are, but also what
alpha, beta, etc, mean.
<https://www.openssl.org/policies/releasestrat.html>
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
601
days inactive
603
days old
8 comments
3 participants
participants (3)
-
Howard Chu -
Ondřej Kuzník -
Quanah Gibson-Mount