Re: stable releases

[Buchan Milne <bgmilne@obsidian.co.za>]

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