From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16217 invoked by alias); 6 Dec 2003 00:04:49 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 16210 invoked from network); 6 Dec 2003 00:04:48 -0000 Received: from unknown (HELO smtp14.fre.skanova.net) (195.67.227.31) by sources.redhat.com with SMTP; 6 Dec 2003 00:04:48 -0000 Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp14.fre.skanova.net (8.12.10/8.12.10) with ESMTP id hB604hrb016436; Sat, 6 Dec 2003 01:04:44 +0100 (CET) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: References: <1070590891.17100.10.camel@odysseus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 06 Dec 2003 01:17:00 -0000 To: Eric McDonald From: Hans Ronne Subject: Re: Release philosophy (was: Re: Miscellaneous Things) Cc: xconq7@sources.redhat.com X-SW-Source: 2003/txt/msg00970.txt.bz2 >> How about if, as soon as all of the serious bugs such as instant crashes >> are fixed, we put out a release candidate (7.5rc1)? Then we can wait >> for anyone to report additional bugs, and we fix them, put out a new >> release candidate (7.5rc2), etc.? Then when a release candidate has >> been out for a while (maybe a week or two) with no new bug reports, we >> release 7.5. > >I feel the same can be accomplished by packaging known good CVS >snapshots. Perhaps the only thing missing from the picture is to >announce the availability of the these snapshots. > >I personally think we should release 7.5 when it's ready. Maybe >the documentation doesn't need to be brought entirely up to date >before a release. But I don't think there should be any >regressions from 7.4.1 as far as "make check" is concerned. And we >are still getting closer to having much more intelligent transport >behavior; I would want to wait until that improvement is in and >working properl; it would be a boost to AI play, IMO. > >> seems to work very nicely for them. And if nothing else, it becomes >> clear to anyone who's paying attention that Xconq is *not* a dead >> project. > >Perhaps it would not appear dead anymore, but it could earn a >reputation as being quite buggy and needing lots of work. I agree with Eric. Let's not rush things when we are almost done. Lincoln has a good point, however, in that more snapshots/release candidates are needed in the final phase before a release. I think Eric's Windows Installers and rpm packages can do this job, but they could perhaps be more frequent. As for the Mac, I had already prepared complete packages two weeks ago, but when the synch error hit us I postponed their release for precisely the reason stated by Eric: that it could earn Xconq a reputation as being buggy and unfinished. With the synch error now being fixed, even though it is only a temporary hack, I will give this another try. Hans