Re: [gentoo-dev] 2004.2 Feature Requests

[Nick Rout <nick@rout.co.nz>]

On Sat, 01 May 2004 15:10:25 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> On Fri, 2004-04-30 at 20:37, Matthew Marlowe wrote:
> > > Hi all -
> > > To start preparing for 2004.2 in July, releng is opening up Feature
> > > Requests that the community would like to see included in 2004.2. The
> > > last day that we are accepting requests is Friday, May 7th at which
> > > point releng will hold a meeting and decide which requests are
> > > feasible for both the alloted time and workload. 
> > 
> > The biggest issues I've had with current and prior gentoo releases is the kernel.   I've configured a couple dozen dell boxes of different models over the last 6 months using 1.4, 2004.0, and 2004.1, and invariably one or more of the following occurs:
> > 
> > - smp kernel locks up completely during hardware detection.
> 
> I find that "smp nohotplug doscsi" seems to be the best bet on any of
> the Dell/Compaq/HP servers that I have dealt with recently.
> 
> > - basic gentoo kernel runs, but doesn't always autodetect raid or network drivers
> > - forced migration to lvm2, because the kernel is configured in 2004.0 for lvm2
> > - 1-3 processors are idle during system installs because of various smp/apic issues 
> 
> See above...
> 
> > Most of these problems would go away if there was a simple documented way to allow users to substitute in their own kernels.  Improving the QA process would help, of course, but I doubt the release eng team has time for this.
> 
> There would be no real way to substitute a kernel, since the livecd is a
> read-only environment.  You could build your own CDs via catalyst with
> any kernel you choose.  I know that is not the best answer, but the
> truth is we try our best to come up with a release that meets the most
> possible configurations.  There are many cases where the CD simply
> doesn't work, and that is a QA issue, but it is definitely something we
> are striving to improve.
> 
> > I know that the new catalyst system is supposed to make things easier, and I'm researching that now...but it definitly doesn't appear to be as simple as it could be.  I'd really like to see future releases work out of the box for Dell servers.  
> 
> Catalyst makes building a live CD easier, but it doesn't do QA for you. 
> This is especially true of the kernels on the CD.  The only thing that
> really does any good is testing.  Perhaps you should join the
> gentoo-releng mailing list and help with testing on the next release. 
> The more machines the beta live CD get exposure to, the more bugs get
> resolved before release.

How about publishing the .spec files that have been used to make the
releases, so that those who want to make their own CD with their own
kernel, or extra features like distcc, can do so.

I have recently made a distcc livecd, and used a combination of the
example catalyst specs (USE="doc" emerge catalyst), hand coding of the
chroot install image etc. It would have been easier if I had the actual
2004.1 .spec files and a decent howto on catalyst (ie a howto  for
people who are not already in the know.) My livecd is largely a hack and
I don't know if i could repeat it. Of course during this time catalyst
has gone from 1.04 to 1.07 and 2004.1 has been released. But hey
it certainly was easier than using livecd-ng this time a year ago!

Not being critical, but catalyst has great potential for all sorts of
things, its just that IMHO its not that easy to get to  grips with.

Anyway,  publication of the .spec files would surely enhance the
"open-ness" of the release cycle.

(Maybe the .spec files are released, but I don't know where to find them?)


> 
> -- 
> Chris Gianelloni
> Developer, Gentoo Linux
> Games Team
> 
> Is your power animal a penguin?

-- 
Nick Rout <nick@rout.co.nz>


--
gentoo-dev@gentoo.org mailing list