stable releases

[<hyc@OpenLDAP.org>]

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

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

> Can someone point me to the applicable URL on http://www.openldap.org
> where it's clear that 2.1.22 should *not* be run in production?
>
> >>> Howard Chu has posted on this list, that 2.1.26 is on the boil,
> >>> presumably because of bugs in 2.1.25.
> >>
> >> So?
> >
> > So you might want to pay attention...
>
> Sure, but I would assume that all important issues would be on
> openldap-announce ...

Yes. I mentioned 2.1.26 in passing, not because of any particularly critical
issues. Real announcements will of course be on the -announce list.

> Look, I'm trying to point out that the status of openldap
> releases could
> be more clear. The information available in openldap-announce
> and on the
> download page seems insufficient
 (I haven't seen updates from
> any other
> vendors from 2.1.22).

Symas is currently providing 2.1.24. (Since we don't build ldbm, the fix in
2.1.25 was not relevant to our bundles.)

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

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support