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