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
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.en...
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
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.
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.
--On Saturday, January 25, 2020 11:22 PM +1100 Hugh McMaster hugh.mcmaster@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
--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder michael@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
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.
On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder michael@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).
--On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder michael@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@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
On 1/28/20 6:30 PM, Quanah Gibson-Mount wrote:
--On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder michael@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@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.
--On Tuesday, January 28, 2020 7:01 PM +0100 Michael Ströder michael@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
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.
--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder michael@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
On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:
--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder michael@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.
--On Wednesday, January 29, 2020 10:09 PM +0100 Michael Ströder michael@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@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
-
Gavin Henry -
Howard Chu -
Hugh McMaster -
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount -
Ryan Tandy