8:12 a.m.
There's been ongoing discussion about making changes to the current release
strategy with OpenLDAP.
Traditionally we've (for the most part) kept new features out of the
release branch and did our best to primarily focus on bug fixes only. There
have clearly been exceptions when warranted (such as support for LMDB,
etc). However, this policy has had the effect of keeping significant
improvements from being made readily available to end users of the
software. To address this, we're looking at implementing the following:
Starting with OpenLDAP 2.5, the OpenLDAP project will use a new release
process.
Odd numbered releases will contain only bug fixes
Even numbered releases will allow for minor new features
This will allow for end users who want stability to focus on odd numbered
releases while allowing those who need/want newer features to be able to
make use of them.
Constructive responses to the new release strategy welcome.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
11:47 a.m.
On Fri, Jan 24, 2020 at 08:12:49AM -0800, Quanah Gibson-Mount wrote:
Starting with OpenLDAP 2.5, the OpenLDAP project will use a new
release process.
Odd numbered releases will contain only bug fixes
Even numbered releases will allow for minor new features
Works for me. Similar to Gavin's note, I'd point out this is opposite to
GNOME's numbering [1] which might occasionally confuse downstreams who
work with both. Speaking of which, is the odd/even numbering intended to
apply to the patch version only (2.5.{1,2}) or the minor version
(2.{5,6}.y) as well?
Why was this particular approach chosen? As opposed to, for example,
doing feature releases more often (e.g. 2.6 as soon as a few months
after 2.5), or adding a fourth version component (2.5.y.z) for strictly
bugfix-only patch releases? Not trying to advocate a change of decision,
just interested in the thought process...
[1]
https://developer.gnome.org/programming-guidelines/stable/versioning.html...
4:22 a.m.
On Sat, 25 Jan 2020 at 06:48, Ryan Tandy wrote:
Why was this particular approach chosen? As opposed to, for example,
doing feature releases more often (e.g. 2.6 as soon as a few months
after 2.5), or adding a fourth version component (2.5.y.z) for strictly
bugfix-only patch releases? Not trying to advocate a change of decision,
just interested in the thought process...
For what it's worth, I'm also interested in the thought process behind
the decision.
As an observer of this project, the length of time between releases in
this project makes it seem far less active than other projects.
So, I personally would like to see more frequent releases, with a
clearer timeline and goals for each release.
Of course, developer time, motivation and other factors come into
play, so it's not cut and dry.
Just my two cents.
Hugh
4:45 a.m.
Hugh McMaster wrote:
On Sat, 25 Jan 2020 at 06:48, Ryan Tandy wrote:
> Why was this particular approach chosen? As opposed to, for example,
> doing feature releases more often (e.g. 2.6 as soon as a few months
> after 2.5), or adding a fourth version component (2.5.y.z) for strictly
> bugfix-only patch releases? Not trying to advocate a change of decision,
> just interested in the thought process...
For what it's worth, I'm also interested in the thought process behind
the decision.
As an observer of this project, the length of time between releases in
this project makes it seem far less active than other projects.
So, I personally would like to see more frequent releases, with a
clearer timeline and goals for each release.
Of course, developer time, motivation and other factors come into
play, so it's not cut and dry.
Just my two cents.
As an open source developer I would prefer to have new features released immediately.
But as a provider of commercial support, we find that our customers are reluctant to
deploy anything with significant changes; they prefer stability. Over the past 7+
years we've catered too much to their need for stability, resulting in many new
features
sitting only in git master, unreleased for years. This new strategy is an attempt to
prevent new features from languishing unreleased for so long, while still providing for
the more stability-sensitive parties out there.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:55 a.m.
This new strategy is an attempt to
prevent new features from languishing unreleased for so long, while still providing for
the more stability-sensitive parties out there.
This is also one of the massive de-motivators as a developer. Creating
something that solves a problem and sits unused. Will be good to see
that not happen for the team.
Gavin.
1:19 p.m.
--On Saturday, January 25, 2020 11:22 PM +1100 Hugh McMaster
<hugh.mcmaster(a)outlook.com> wrote:
As an observer of this project, the length of time between releases
in
this project makes it seem far less active than other projects.
So, I personally would like to see more frequent releases, with a
clearer timeline and goals for each release.
I've never quite understood this mindset. To me, frequent releases
generally indicate an immature, unstable, and buggy product. ;)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:17 p.m.
--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
> To me, frequent releases
> generally indicate an immature, unstable, and buggy product. ;)
Are you sarcastic here?
No, not at all. I would say OpenLDAP has too few releases in a year (only
1-2 currently for most years, unfortunately), so having more frequent
releases for it is probably a good thing. But a piece of software in
general that is releasing constantly? Not a fan of it at all, and haven't
seen it as a good thing as far as softare quality is concerned. There's
plenty of software that releases much less frequently than OpenLDAP as
well, because there isn't a driving need for it to have a new release.
And as Howard noted, there's a balance to strike between stability and
feature development. If we release every 2 weeks, but slapd core dumps 90%
of the time, is that really better? Sure, the project looks more "active",
but I wouldn't see that as a benefit/gain.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:46 p.m.
On Mon, Jan 27, 2020 at 02:17:13PM -0800, Quanah Gibson-Mount wrote:
No, not at all. I would say OpenLDAP has too few releases in a year
(only
1-2 currently for most years, unfortunately), so having more frequent
releases for it is probably a good thing. But a piece of software in
general that is releasing constantly? Not a fan of it at all, and haven't
seen it as a good thing as far as softare quality is concerned. There's
plenty of software that releases much less frequently than OpenLDAP as well,
because there isn't a driving need for it to have a new release.
There's always as much to do as many people you have on hand. With a
large team, release schedules that seem to work best nowadays look
like Linux/Python/PostgreSQL where you have a time based feature release
schedule so whatever isn't ready yet just waits for the next merge
window and bugfix releases for the currently supported version come as
and when needed.
Let's see how quickly we can get from a first 2.5 release to more
general adoption and see if we can maybe ride the wave a bit, renaming
2.5 to a 2.6 when people are more happy with it and starting 2.7 at the
same time, which I think is what you meant by this proposal?
And as Howard noted, there's a balance to strike between
stability and
feature development. If we release every 2 weeks, but slapd core dumps 90%
of the time, is that really better? Sure, the project looks more "active",
but I wouldn't see that as a benefit/gain.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
1:08 a.m.
On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
> On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
>> To me, frequent releases
>> generally indicate an immature, unstable, and buggy product. ;)
>
> Are you sarcastic here?
No, not at all. [..] If we release every 2 weeks, but slapd core
dumps 90% of the time, is that really better? Sure, the project
looks more "active", but I wouldn't see that as a benefit/gain.
ITS#9124 is known since almost two months now and there's no upstream
release with a fix. (And remember that I've tested RE24 branch revealing
that the first fix was seg faulting.)
=> The OpenLDAP project needs more continuous testing to be able to
provide quicker releases in such an emergency case.
Just being slower and leave such a security issue to packagers adding
back-ports is not stable (for whatever definition of "stable").
Ciao, Michael.
P.S.: And yes, cyrus-sasl is even worse by not handling CVE-2019-19906
(first filed as ITS#9123).
9:30 a.m.
--On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
> <michael(a)stroeder.com> wrote:
>
>> On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
>>> To me, frequent releases
>>> generally indicate an immature, unstable, and buggy product. ;)
>>
>> Are you sarcastic here?
>
> No, not at all. [..] If we release every 2 weeks, but slapd core
> dumps 90% of the time, is that really better? Sure, the project
> looks more "active", but I wouldn't see that as a benefit/gain.
ITS#9124 is known since almost two months now and there's no upstream
release with a fix. (And remember that I've tested RE24 branch revealing
that the first fix was seg faulting.)
You're switching topics. If you want to have a conversation, please stay
on topic. Otherwise it's just a waste of time. The upcoming changes to
the entire OpenLDAP project infrastructure have already been discussed,
including CI, etc.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
10:01 a.m.
On 1/28/20 6:30 PM, Quanah Gibson-Mount wrote:
--On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
> On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
>> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
>> <michael(a)stroeder.com> wrote:
>>
>>> On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
>>>> To me, frequent releases
>>>> generally indicate an immature, unstable, and buggy product. ;)
>>>
>>> Are you sarcastic here?
>>
>> No, not at all. [..] If we release every 2 weeks, but slapd core
>> dumps 90% of the time, is that really better? Sure, the project
>> looks more "active", but I wouldn't see that as a benefit/gain.
> ITS#9124 is known since almost two months now and there's no upstream
> release with a fix. (And remember that I've tested RE24 branch revealing
> that the first fix was seg faulting.)
You're switching topics.
Nope. I'm very much on-topic.
ITS#9124 is a good example that the "stable" status of the release
branch is just an assumption. It makes clear that a quicker process for
more urgent releases is needed.
I'm not blaming anybody that there are bugs. We are all humans and we
make faults. Period. But stating that there are bugs in "stable"
releases is what really concerns me.
Today releasing is already way too slow. And I'm concerned that a
release policy with additional constraints, as suggested with
odd-/even-numbered releases, will make it even harder to get important
fixes out of the door.
Ciao, Michael.
10:45 a.m.
--On Tuesday, January 28, 2020 7:01 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
Today releasing is already way too slow. And I'm concerned that
a
release policy with additional constraints, as suggested with
odd-/even-numbered releases, will make it even harder to get important
fixes out of the door.
I don't disagree that our current process is too slow. There's a lot of
different gating factors, such as only 3 strongly active project members
(Howard, Ondrej, myself), an badly out of date infrastructure, etc. That
last bit we're working on addressing, but then it takes time away from
getting new releases out in the meantime. Also, I really really really
would like 2.4.49 to be the end of 2.4, outside the possibility of some
critical CVEs.
As for the new release numbering, I've thought about that as well, and was
thinking potentially we may skip a release. I.e., go from 2.5.1 to 2.5.3
with no 2.5.2 if we just need to do a bug fix release (or vice versa if we
match Gnome's strategy as Ryan brought up.
But my point was, I think it's a fallacy to tie software quality and
frequency of releases. I encounter way too much software today that
releases frequently, but what it releases is poorly (or not at all) QA'd,
etc. And it's a nightmare to deal with. I'd rather they slowed down and
got their software in better shape than constantly release, well, crap. ;)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
9:52 a.m.
On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
Also, I really really really would like 2.4.49 to be the end of 2.4,
outside the possibility of some critical CVEs.
But that's just your personal
goal which is leaving systems in
production unpatched until you feel you're done. IMO that's totally wrong.
If releasing a new version is so much stress then there's something
fundamentally broken in the whole process.
I'd like to emphasize here that this is likely not your personal fault.
It rather shows a deficiencies of the infrastructure. I've offered help
in the past various times.
As for the new release numbering, I've thought about that as
well, and
was thinking potentially we may skip a release. I.e., go from 2.5.1 to
2.5.3 with no 2.5.2 if we just need to do a bug fix release (or vice
versa if we match Gnome's strategy as Ryan brought up.
I'm not a friend of artificial constraints which likely do not fit
reality later. I think there were good reasons why this scheme was
abandoned for Linux kernel development. I don't know the details though.
But my point was, I think it's a fallacy to tie software quality
and
frequency of releases.
Of course such a simple assumption is bullshit. To me the list of
outstanding unfixed/unreleased issues matters most.
Ciao, Michael.
10:49 a.m.
--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
> Also, I really really really would like 2.4.49 to be the end of 2.4,
> outside the possibility of some critical CVEs.
But that's just your personal goal which is leaving systems in
production unpatched until you feel you're done. IMO that's totally wrong.
No, it's the project goal to switch the focus to getting OpenLDAP 2.5
released. At some point, work on 2.4 needs to stop. Unless you'd like to
see 2.5 dragged out another decade?
Of course such a simple assumption is bullshit. To me the list of
outstanding unfixed/unreleased issues matters most.
Which ties into the above and why 2.4 needs to be sunsetted.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1:09 p.m.
On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:
--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
> On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
>> Also, I really really really would like 2.4.49 to be the end of 2.4,
>> outside the possibility of some critical CVEs.
> But that's just your personal goal which is leaving systems in
> production unpatched until you feel you're done. IMO that's totally
> wrong.
No, it's the project goal to switch the focus to getting OpenLDAP 2.5
released. At some point, work on 2.4 needs to stop. Unless you'd like
to see 2.5 dragged out another decade?
Is it realistic to enforce that 2.4.49 will be the final 2.4.x release
before we saw at least one 2.5.x release? Sounds really strange to me.
Ciao, Michael.
1:15 p.m.
--On Wednesday, January 29, 2020 10:09 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:
> --On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
> <michael(a)stroeder.com> wrote:
>
>> On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
>>> Also, I really really really would like 2.4.49 to be the end of 2.4,
>>> outside the possibility of some critical CVEs.
>> But that's just your personal goal which is leaving systems in
>> production unpatched until you feel you're done. IMO that's totally
>> wrong.
>
> No, it's the project goal to switch the focus to getting OpenLDAP 2.5
> released. At some point, work on 2.4 needs to stop. Unless you'd like
> to see 2.5 dragged out another decade?
Is it realistic to enforce that 2.4.49 will be the final 2.4.x release
before we saw at least one 2.5.x release? Sounds really strange to me.
I never said it would absolutely be the last release. I said I would
really really really like it to be the last release. Please pay attention
to what is actually written. If there becomes enough reason to create
another 2.4.x release, then clearly one will have to be made. We did this
with 2.3 as well.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1407
days inactive
1412
days old
16 comments
7 participants
participants (7)
-
Gavin Henry -
Howard Chu -
Hugh McMaster -
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount -
Ryan Tandy