public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Karl Trygve Kalleberg <karltk@prosalg.no>
To: gentoo-dev@gentoo.org
Subject: [gentoo-dev] What should be in place before 1.0 release
Date: Sun Oct 14 08:38:01 2001	[thread overview]
Message-ID: <20011014163620.626d13c5.karltk@prosalg.no> (raw)

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



             reply	other threads:[~2001-10-14 14:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-14  8:38 Karl Trygve Kalleberg [this message]
2001-10-14 10:51 ` [gentoo-dev] What should be in place before 1.0 release Dan C
2001-10-14 14:37 ` Blue Lizard
2001-10-14 15:36   ` Karl Trygve Kalleberg
2001-10-15  3:14     ` Mikael Hallendal
2001-10-15  3:36       ` Blue Lizard
2001-10-15  6:05         ` Mikael Hallendal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011014163620.626d13c5.karltk@prosalg.no \
    --to=karltk@prosalg.no \
    --cc=gentoo-dev@cvs.gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox