Re: stable releases

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Buchan,

It's assumed, like in most open software projects, that
those providing good 3rd party packagers are reasonable
"tuned in" as to what's going "release engineering"
wise (announcements, bug reports, list traffic, etc.).
If you choose not to be, well, that's your business.

(Note that I could say the above to any *user* of
OpenLDAP Software as well.  I don't think we've ever
said that OpenLDAP Software is "install and forget"
software.)

Kurt

At 12:45 AM 1/21/2004, Buchan Milne wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>hyc@OpenLDAP.org wrote:
>>>-----Original Message-----
>>>From: owner-openldap-software@OpenLDAP.org
>>>[mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Buchan Milne
>>
>>
>>>I am not worried about the new release being stable, I am
>>>worried about
>>>whether an old release is stable or not.
>>
>>
>> If the code was stable then we wouldn't waste our time releasing bug fixes
>> for it now, would we? We could just devote all of our time to the new
>> features in the new branch.
>
>Or, you might be backporting new features from the new branch, or
>something similar. Many other software packages release new minor
>versions that aren't necessarily critical updates.
>
>>
>>
>>>If each time a new stable release is made, that means that
>>>all previous
>>>releases are not stable, and should have updates made by vendors, it's
>>>not very clear ...
>>
>>
>> Read the FAQ. http://www.openldap.org/faq/index.cgi?file=225 The "stable"
>> release is the last "general use" release that has demonstrated itself as
>> being stable. By definition, there can only be one "last" release. So
>again
>> by definition, when a given release is marked stable that means that all
>> previous releases are not stable.
>
>That is not logical. Sorry. The FAQ is not sufficient in addressing
>this. If this is really true, it should say something along the lines of
>"only one release is ever simultaneously stable, as soon as a new stable
>release is made, all users must be encouraged to upgrade immediately to
>avoid potential crashes/DOSs, and all vendors should provide updates".
>
> >>If you want to continue to tell me to read the
>>>lists, fine, but wouldn't it be a better solution just to note on the
>>>download page that some people have experienced severe problems with
>>>2.1.22, and that upgrades should be provided (and possibly a
>>>similar one
>>>to the announce list?). I think it would save time for everyone
>>>involved, but maybe that's just me.
>>
>>
>> That wouldn't accomplish anything. "Some people experienced problems"
>- - which
>> people? What problems? Will this affect my installation?
>
>Yes, answers to these should be provided ...
>
>
>> Such a statement is
>> useless. The announcements list the bug IDs, and the area of function that
>> was affected. It's up to the end-user to decide whether the affected
>> functionality is of any importance. 2.1.23 fixes a "back-bdb cache
>crash." If
>> you only use back-ldbm, then there's probably no reason to worry about
>this
>> release. 2.1.24 fixes "slurpd memory leaks". If you don't do
>replication, you
>> probably don't need to worry about this release either.
>
>And 2.1.22 slaves crash where 2.1.25 slaves don't. We've now covered
>about 75% of use cases for problems fixed between 2.1.22 and 2.1.25
>
>> But it's not up to us
>> to tell you that you need to upgrade, because we don't know what
>features you
>> use. Obviously it's a problem for *somebody*, which is why we release the
>> fixes.
>>
>> As with anything in life, you have to use your brain. As the LDAP
>> administrator, you have to decide what's important to you. As a distro
>> packager, you have a different challenge - like us on the Project, you
>don't
>> know what selection of features your users will use. If you want to
>provide
>> something that is useful to the broadest audience, then you have to
>aim for
>> correct function across the largest feature set. Your constraints are much
>> the same as those on the Project itself. That *should* tell you that
>you need
>> to release at close to the same times as the Project does, unless you
>narrow
>> your scope and you know that certain bugfixes don't affect the feature set
>> that you offer.
>>
>> For example, there is a bug in 2.1 back-ldbm that can cause a crash on
>a bad
>> ModRdn request. The bug has been part of back-ldbm for years, and I
>recently
>> wrote a fix for it that's in 2.2. I am debating whether to spend the
>effort
>> to backport the fix from CVS/2.2. It may make it into 2.1.26, it may
>not. Is
>> it critical? Not to me, because I don't use back-ldbm, and it goes without
>> saying that back-ldbm is unreliable
>
>But of course users who upgraded from 2.0.x without changing db backends
>will still have the problem.
>
>>, so the fact that this bug has been
>> recorded is just par for the course. If it is fixed in 2.1.26, will
>that make
>> 2.1.26 better/"more stable" than 2.1.25? Again, that really depends on
>you,
>> and whether you use back-ldbm yourself.
>>
>> I would say any bug that results in slapd crashing presents the
>opportunity
>> for a denial-of-service attack on a production installation, and so if the
>> fix is available, it should be used. But this is obvious, it should go
>> without saying.
>
>But I don't remember the release announcement for 2.1.23 saying it fixed
>a crash/DOS bug in so many words (unless one is familiar with the
>detailed implementation of openldap, which many users will not be).
>
>It seems like you don't see any reason to lower the barrier to having a
>stable openldap setup. Many other projects do. I am prepared to do my
>part (push for updates for at least Mandrake and help in
>providing/testing them), but at present you seem to think this is a
>waste of time. So, then I guess I can spend my time doing other things too.
>
>Regards,
>Buchan
>
>- --
>Buchan Milne
>Senior Support Technician
>Obsidian Systems
>http://www.obsidian.co.za
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFADjxFrJK6UGDSBKcRAn5NAKCxGSjhsGdtkISGR88NixwvZjjpqACfVYBe
>BtsaaK2vJHggVoS9pHh5IOA=
>=7C1e
>-----END PGP SIGNATURE-----