Re: New release policy for OpenLDAP

[Quanah Gibson-Mount]

--On Wednesday, January 29, 2020 10:09 PM +0100 Michael Ströder 
 wrote:



On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:

--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
 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:

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:
> --On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
>  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.

Re: New release policy for OpenLDAP

[Quanah Gibson-Mount]

--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder 
 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:

Re: New release policy for OpenLDAP

[Michael Ströder]

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.

Re: New release policy for OpenLDAP

[Hugh McMaster]

On Wed, 29 Jan 2020 at 05:46, Quanah Gibson-Mount wrote:

> 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.


No-one was suggesting a two-week release cycle (e.g. Wine) or three major
releases a year (e.g. ICU). But there comes a point where simply releasing
bug fixes (although very important for stability) for many years at a time
delays the release of important other work.

That’s what Howard wants to address with this change.

Out of interest, what frequency of minor and patch release do believe is
appropriate for this project?

Hugh

Re: New release policy for OpenLDAP

[Quanah Gibson-Mount]

--On Tuesday, January 28, 2020 7:01 PM +0100 Michael Ströder 
 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:

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/28/20 6:30 PM, Quanah Gibson-Mount wrote:
> --On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder
>  wrote:
> 
>> On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
>>> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
>>>  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.

Re: New release policy for OpenLDAP

[Ondřej Kuzník]

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

Re: New release policy for OpenLDAP

[Quanah Gibson-Mount]

--On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder 
 wrote:



On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:

--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
 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:

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
>  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).

Re: New release policy for OpenLDAP

[Quanah Gibson-Mount]

--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder 
 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:

Re: New release policy for OpenLDAP

[Michael Ströder]

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?

Ciao, Michael.

Re: New release policy for OpenLDAP

[Quanah Gibson-Mount]

--On Saturday, January 25, 2020 11:22 PM +1100 Hugh McMaster 
 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:

Re: New release policy for OpenLDAP

[Gavin Henry]

> 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.

Re: New release policy for OpenLDAP

[Howard Chu]

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/

Re: New release policy for OpenLDAP

[Hugh McMaster]

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

Re: New release policy for OpenLDAP

[Ryan Tandy]

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#stable-unstable-versions

Re: New release policy for OpenLDAP

[Gavin Henry]

>> Constructive responses to the new release strategy welcome.
>
>
> Sounds good! Although odd numbers seems to feel like something risky, i.e. a 
> new feature, whereas even numbers feel nice and comfy, boring and just bug 
> fixes. Maybe just me!

How does that fit with https://semver.org/ ?

==
Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
==

Re: New release policy for OpenLDAP

[Gavin Henry]

> 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.
>

Sounds good! Although odd numbers seems to feel like something risky, i.e.
a new feature, whereas even numbers feel nice and comfy, boring and just
bug fixes. Maybe just me!

Gavin.

-- 
Kind Regards,
Gavin Henry.