[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: stable releases

To: openldap-software@OpenLDAP.org
Subject: Re: stable releases
From: "Medievalist" <ldap@hbcs.org>
Date: Wed, 21 Jan 2004 17:07:11 -0500
Content-description: Mail message body
In-reply-to: <6.0.1.1.0.20040121073527.02b4e058@127.0.0.1>
References: <400E3C46.6000007@obsidian.co.za>
Stable clearly means different things to different folks.  To me it means 
something that never crashes - which is pretty close to "install and forget".

Wouldn't it be easier to ask a distributor (say Red Hat) to create new .rpms 
than to read (much less answer) the eighty bazillion "why doesn't my OpenLDAP 
work" posts their standard packages engender?  Hmmrmph; I'll BCC: this message 
to Nalin Dahyabhai at Red Hat and see what happens.

--Charlie

On 21 Jan 2004 at 7:57, Kurt D. Zeilenga wrote:

> 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-----
Follow-Ups:
- Re: stable releases
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
References:
- Re: stable releases
  - From: Buchan Milne <bgmilne@obsidian.co.za>
- Re: stable releases
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Prev by Date: Re: "dynamic" acls
Next by Date: Re: Redhat 9 problems
Index(es):
- Chronological
- Thread