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=1.5 required=5.0 tests=DATE_IN_PAST_12_24, DMARC_MISSING,INVALID_DATE,MAILING_LIST_MULTI,RDNS_NONE autolearn=no autolearn_force=no version=4.0.0 Received: from [66.56.80.159] (helo=att-56-80-159.localhost.localdomain ident=postfix) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15ss0K-0000qM-00 for gentoo-dev@cvs.gentoo.org; Sun, 14 Oct 2001 14:37:00 -0600 Received: from dofty.zzn.com (localhost.localdomain [127.0.0.1]) by att-56-80-159.localhost.localdomain (Postfix) with ESMTP id 79965175F1 for ; Sun, 14 Oct 2001 16:37:24 -0400 (EDT) Message-ID: <3BC9F783.6000300@dofty.zzn.com> From: Blue Lizard User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: gentoo-dev@cvs.gentoo.org Subject: Re: [gentoo-dev] What should be in place before 1.0 release References: <20011014163620.626d13c5.karltk@prosalg.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Sun Oct 14 14:37:02 2001 X-Original-Date: Sun, 14 Oct 2001 16:37:23 -0400 X-Archives-Salt: 0f1f9f84-9158-424b-b747-4af545020512 X-Archives-Hash: 2a938dd2ee85e4a189d7d41ef200708b Karl Trygve Kalleberg wrote: > 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. bugzilla _could_ handle this, but while it is technically ready enough our development team is in no way prepared to handle the influx of new users that would find it a pain in the neck to use. > 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. Personally, I was surprised at the quality of the 1.0_rc6 install from source guide. Could be some improvements, but it is a nice place to start from. > 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. A good way for ebuild to handle apps that dont flag/opt well would be nice, other than hard coding everything :) Like if a build is known to spark out when a given portion is compiled -O3, knock it down to -O2 (IOW ebuild parses out flags in make.conf and handles wisely, according to the writers instructions.) > 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. You are out of your mind. One week? DUDE! This is a 1.0 release of what could be a major mainstream linux distribution. One week? > 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 ;) Yes, and the idea is that up until the very minute that feature freeze goes into effect, anything and everything goes on that list. Someone gets the slightest little notion of something that'd be cool and POOF!, on the list. Just that stuff more whimish than others would be in a diff priority class for obvious reasons. > 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.. Who is in charge of evangelism and propoganda right now? > > 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. > It's not? awwwwwwwww. ;P