[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: stable releases



Regarding stable software releases (and then especially Openldap
releases): The forwarded message from a resigned Ximian Evolution
Windows LDAP user. Sorry that this comes *out of the thread quoted
above* - I hate it when people do that.

ons, 21.01.2004 kl. 16.57 skrev Kurt D. Zeilenga: 

> 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-----
-- 
mail: billy - at - billy.demon.nl
http://www.billy.demon.nl
--- Begin Message ---
>From evolution-admin@lists.ximian.com  Wed Jan 21 17: 30:30 2004
Return-Path: <evolution-admin@lists.ximian.com>
X-Original-To: tonye@billy.demon.nl
Delivered-To: tonye@billy.demon.nl
Received: from punt-15.mail.nl.demon.net (punt-15.mail.nl.demon.net
	[194.159.73.24]) by billy.demon.nl (Postfix) with SMTP id 5302640893 for
	<tonye@billy.demon.nl>; Wed, 21 Jan 2004 17:30:29 +0100 (CET)
Received: from store-21.mail.nl.demon.net by mailstore for
	tonye@billy.demon.nl id 1AjJSo-000CGS-4t-000CGd; Wed, 21 Jan 2004 14:36:16
	+0000
Received: from incoming-20.mail.nl.demon.net ([194.159.73.160]:3877) by
	store-21.mail.nl.demon.net with esmtp (Exim 4.24) id 1AjJSo-000CGS-4t for
	tonye@billy.demon.nl; Wed, 21 Jan 2004 14:36:14 +0000
Received: from headcheese.ximian.com ([130.57.169.17]:49728
	helo=lists.ximian.com) by incoming-20.mail.nl.demon.net with esmtp (Exim
	4.24) id 1AjJSo-0005rQ-5x for tonye@billy.demon.nl; Wed, 21 Jan 2004
	14:36:14 +0000
Received: from headcheese.ximian.com (localhost [127.0.0.1]) by
	lists.ximian.com (Postfix) with ESMTP id 34EC012421A; Wed, 21 Jan 2004
	09:36:10 -0500 (EST)
Received: by lists.ximian.com (Postfix, from userid 38) id E98E012421A;
	Wed, 21 Jan 2004 09:35:08 -0500 (EST)
Received: from james.netnea.com (gstserv.netnea.com [213.200.225.210]) by
	lists.ximian.com (Postfix) with ESMTP id 29B48124326 for
	<evolution@lists.ximian.com>; Wed, 21 Jan 2004 09:34:25 -0500 (EST)
Received: from big.bueche.ch (adsl-212-101-16-88.solnet.ch [212.101.16.88])
	by james.netnea.com (8.12.10+Sun/8.12.2) with ESMTP id i0LEYJbS017058; Wed,
	21 Jan 2004 15:34:20 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by big.bueche.ch (Postfix)
	with ESMTP id D6356141B0; Wed, 21 Jan 2004 15:33:51 +0100 (MET)
Subject: Re: [Evolution] Message composition freezes regulary
From: Charles Bueche <charles@bueche.ch>
To: J Black <evolution@jblack.org>
Cc: evolution@lists.ximian.com
In-Reply-To: <1074670228.5244.41.camel@prism>
References: <1074670228.5244.41.camel@prism>
Content-Type: text/plain
Message-Id: <1074695631.31841.2.camel@bluez.bueche.ch>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
X-Spam-Status: No, hits=-32.4 required=5.0
	tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.53
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)
Sender: evolution-admin@lists.ximian.com
Errors-To: evolution-admin@lists.ximian.com
X-BeenThere: evolution@lists.ximian.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:evolution-request@lists.ximian.com?subject=help>
List-Post: <mailto:evolution@lists.ximian.com>
List-Subscribe: <http://lists.ximian.com/mailman/listinfo/evolution>,
	<mailto:evolution-request@lists.ximian.com?subject=subscribe>
List-Id: Evolution users mailing list. <evolution.lists.ximian.com>
List-Unsubscribe: <http://lists.ximian.com/mailman/listinfo/evolution>,
	<mailto:evolution-request@lists.ximian.com?subject=unsubscribe>
List-Archive: <http://lists.ximian.com/archives/public/evolution/>
Date: Wed, 21 Jan 2004 15:33:51 +0100
Content-Transfer-Encoding: 7bit

Hi,

ust an idea : do you have a directory server configured ?

I just found out that my evo 1.5 can't be told to timeout after 10
seconds on LDAP requests. The LDAP server here being Window$, it crash
often enough for me to have such timeouts (well, not exactly every
minute, but not much better :-)

Charles

On Wed, 2004-01-21 at 08:30, J Black wrote:
> Hello.
> 
> I'm using Evolution 1.4.4 on Mandrake 9.2.  I've had a problem with
> Evolution ever since installing these versions of Mandrake and
> Evolution:
> 
> Whenever I'm editing a message and typing away, the compose window
> freezes for about 5 seconds every 60 seconds.  The cursor stops
> blinking, and whatever I type doesn't appear until the 5 seconds is up. 
> (It's done it twice just typing these sentences!)  Even typing a single
> character into the message window is enough to trigger this behavior.
> 
> I don't notice this in other apps like Mozilla or OpenOffice, and I
> didn't have this problem in Mandrake 9.1 (don't know which version of
> Evolution.)
> 
> I've tried disabling message retrieval and spell check, but that doesn't
> help.
> 
> Any ideas on what might be the problem?
> What does Evolution do every minute that might be causing the problem?
> 
> Thanks in advance,
> 
> - J Black
> 
> 
> _______________________________________________
> evolution maillist  -  evolution@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/evolution
-- 
Charles Bueche <charles@bueche.ch>
sand, snow, wave, wind and net -surfer

_______________________________________________
evolution maillist  -  evolution@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution

--- End Message ---