Re: [gentoo-dev] What should be in place before 1.0 release

[Blue Lizard <webmaster@dofty.zzn.com>]

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