From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DATE_IN_PAST_12_24, DMARC_MISSING,INVALID_DATE,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from janus.prosalg.no ([213.236.139.1] helo=io.adm.prosalg.no) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15smO3-0008OE-00 for gentoo-dev@gentoo.org; Sun, 14 Oct 2001 08:37:07 -0600 Received: from b223a.studby.ntnu.no ([129.241.126.223] helo=motvind) by io.adm.prosalg.no with asmtp (Exim 3.33 #1 (Debian)) id 15smH9-0007Co-00 for ; Sun, 14 Oct 2001 16:29:59 +0200 From: Karl Trygve Kalleberg To: gentoo-dev@gentoo.org Message-Id: <20011014163620.626d13c5.karltk@prosalg.no> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] What should be in place before 1.0 release Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org X-Reply-To: karltk@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Sun Oct 14 08:38:01 2001 X-Original-Date: Sun, 14 Oct 2001 16:36:20 +0200 X-Archives-Salt: dab6baae-e35e-4ce7-b940-53348ca84034 X-Archives-Hash: 0a59013e353c217894a61c6d11b6fa7c Hi gang. I just like to voice my opinion about issues that should be addressed before the release of Gentoo Linux 1.0 (hurrah!) While I can to a large degree accept that the distro itself is technically ready enough to be released, our development team is in no way prepared to handle the influx of new users. At minimum, we should have the following points fixed: 1) A proper bug-reporting system. We simply won't be able to keep track of the issues cropping up in gentoo-{dev,users,ebuild,whatever} given the current developer situation. 2) A flawless installation guide. This means that we should do the installation of the 1.0 version in a handful of different configurations and make certain the installation guide is not only correct, but succinct and unambiguous. This is tricky, but every hour we spend fixing it before final release, will save us tenfold down the line. 3) Verify that all our ebuilds actually work as advertised. Some ebuilds seem to be more error-prone than others (minicom, koffice). The ones that have any problems whatsoever should be masked out until we know that they really work. 4) In a related note, we should have a "grace-period"/"codeslush"/"codefreeze" of at least one week where we do not add new stuff, and do nothing but bug-squashing. We should verify that *all* ebuilds have been tested, preferrably with *all* their optional USE arguments. 5) We should have a release plan on the web, a task-list if you will, where we check off items as we progress along to 1.0. This will hopefully work as a great motivator once we're over half-way ;) 6) We should officially nominate a Release Manager (I guess this will be drobbins, but it would be nice for everybody, including non-developers, ie hardcore Gentoo testers to know who's neck is on the block ;). 7) Perhaps we even should have a release team that acted as drobbins' elven helpers and make certain that all the items on the task-list are addressed in a timely fashion. Perhaps all the developers should just act as elven helpers.. Hope this sets thoughts churning. If we want 1.0 to be stable and good, we will have to put a lot of effort into it, and do so in a structured fashion. The all-nighter "throw code at it until it works" is NOT an option. Kind regards, Karl T