Alan Cox wrote (pulled from Digest Version):
> FC4 was not the greatest Fedora, as a Red
> Hat developer I've actually gone back to FC3 for most stuff.
Now more than ever, I sure wish to God that Red Hat go back to
I.e., whenever you change the kernel, GLibC and/or GCC, or any other
"core" component, slap a ".0" on it.
Bryan J. Smith b.j.smith(a)ieee.org http://thebs413.blogspot.com
The best things in life are NOT free - which is why life is easiest if
you save all the bills until you can share them with the perfect woman
On Thu, 08 Sep 2005 15:38:27 +0530, Rahul Sundaram <sundaram(a)redhat.com> wrote:
> >How can the yet-to-be founded FC foundation help external contributers
> >(Such as Mr. Adams) get their fixes into the system faster?
> There is no need to way for a foundation for such things. Users or
> developers can report such issues in bugzilla. Precise and helpful
> information will probably result in a quicker fix
Patches are especially appreciated, even if they are incorrect in
some way. You don't have to be some kind of committer to be a developer.
I would like to suggest including "git" in FC. Why in the Core?
Because in addition to its uses as an SCM, it's also really useful for
managing user configurables since it's an SCM that handles sparse trees
just fine. Thus, one can have a ~/.git directory and check in the files
one wants to have under control. However, for this to be useful, git
really needs to be available by default in as many places as possible.
(Or later today, depending on your perspective.)
A moderate rework of some of the X configuration code has
landed, and will be in rawhide tomorrow. Instead of mapping
devices to an abstract 'card', and then matching that 'card'
to a driver, we just match directly to drivers now.
Some related changes to driver mapping in general landed
at the same time, so device handling in anaconda may be odd.
as a reference, is it suitable and feasible to try to make a similar
solution for fc5 available under the "official" fedora project
I'm not saying make the set of floppies available as part of the
install media(though that would be the holy grail scenario). But as a
first time out... if the community tracked the test releases and made
a floppy install method similar to what is outlined in the url for
testers to test.. could a home for it be found on the official
download pages and an instructions on how to use it included in the
release notes for the final fc5 release?
I would like to debug the inotify problem found on head, try to add
V4L2 support for pwlib and work on Xen setup. For this I need a Rawhide
install, this sounds simple and resinstalling a rawhide used to be a copy
of the image boot to an USB key, use quickstart to point to a local
mirror and in 20 mn have a new setup ready to work on. I really didn't
expected to face the following mess:
First trying the installer, I have a local copy of the rawhide mirror,
any attempt to bout from the boot image results in anaconda failing
not able to import os or sys at the python level, i.e. not the kind of
bug you can work around by yourself if you're not intimate with anaconda:
Running anaconda, the Fedora Core system installer - please wait
Could not find platform independant libraries <prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last)
File "/usr/bin/anaconda", line 28, in ?
import sys, os
ImportError: no module named os
installer exited abnormally
it had been that way for months, general feedback is installer does
not work, and that the expected way is to upgrade from a FC4 setup.
So okay it's takes way more time but I reinstall a FC4 partition from
scratch, then modify the yum.conf to point to my local rawhide repository.
I upgrade yum, I upgrade the kernel and one hours and a half later I try
to reboot. Dies as all init level respawns too fast. 2.6.13-1.1538_FC5 won't
boot but the old 2.6.11-1.1369_FC4 still allows to boot.
So okay one may need to update everything yum update launched....
Which means a transaction with 510 packages and 881 megabytes of data which
are downloaded *first* onto the local disk before even starting to test the
transaction. 15 mn later I'm greeted with:
('installing package openoffice.org-writer-1.9.127-1.2.0.fc5 needs 764MB on the / filesystem', (9, '/', 800161792L))
Of course downloading all packages locally, plus keeping them for the
entire transaction, plus the conservative (good) rpm checks for disk space
means one need 2 Gigabyte free on the partition (and this is far far from
a full install) to just run the upgrade.
So removing a bunch of beefy packages, I regain enough space on the partition
to get the transaction to start. 954 packages to be updated/cleaned, the
transaction took 35 minutes.
Then reboot ... 2.6.13-1.1538_FC5 still fails to boot all process forked
by init just seems to crash, but booting the old 2.6.11-1.1369_FC4 works.
Half a day later I still don't have a setup to test inotify or recent Xen.
Do we really expect to get significant feedback on a system that is so
hard to install or run ? Delaying the release of FC5 raises the risk of
decoupling from our user base and people who test bleeding edge, with a
HEAD that is so hard to install and get running people who want to test
new stuff have an easier upgrade path by installing Ubuntu (and maybe
openSuse) than trying to get Rawhide going. I am afraid the current state
of Rawhide just means silent exodus of the people who really help building
the distro. The fact that the installer has been broken for months in my
experience is a very significant threat, and increase the risk associated
to delaying FC5 to an extend we didn't anticipated.
In a nutshell I'm very concerned that Rawhide being nearly impossible to
install or run by mere mortals the delay between FC4 and FC5 will just
result in loosing a large part of our user base to other distro more
up to date and still easy to install and run.
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On 9/7/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> On 9/7/05, Paul A Houle <ph18(a)cornell.edu> wrote:
> > I don't really know how bad the problems are. Most of the codepath
> > involved in the install is going to be on the CD and not on the rpms.
> > Most of the rpms are getting 'tested' by people who are running
> > up2date.
> anaconda has "magic"..voodoo magic. Perhaps its best not to assume
> that up2date and anaconda treat depresolution equally.
> The main questions I see are
> > (i) will something about the rpms cause the installer to malfunction?
> > (ii) will something go wrong during firstboot... this is the one code
> > path that isn't getting tested daily by Fedora users.
> > Careful software engineering can minimize the codepath affected by
> > (i) and (ii) problems and reduce the chance of problems.
> careful software engineering certaintly sounds like manpower to me.
> Who exactly is going to be watching out for this? Someone is going to
> actually have to do the testing and catch problems. Especially if the
> goal is to respin to fix install time problems. Anytime you go into
> the code to fix something you can break something...regardless of how
> "careful" your software engineering is. If there isn't the manpower to
> do the testing after a change in made.. you end up with a situation
> where people having problems unique to a respin. Its hard enough
> helping people through well understood cornercase installer problems
> with the release isos 2 months after a release. You start throwing
> monthly isos out there without serious regression testing and you get
> into deeply uncomparable situations. I'm certaintly not going to stick
> my neck out and attempt to help people with a respin that I havent
> used. And I'm certaintly not going to be doing weekly or monthly
> respin based installs on top of tracking rawhide I don't have the
> hardware to keep up with that.
> > A less ambitious goal is to keep the installer the same and change
> > the rpm's. This won't solve everybody's problems, but it will make
> > Fedora installs faster around my house.
> Sometimes I find it better to choose reliably broken with known
> workarounds..than unreliably new. I'm more than willing to get on the
> bandwagon once someone shows me with that scripted respins of the
> distro like this don't need aggressive pre-release testing by putting
> these things out and the wild and collecting usage information and
> bugreports. I'm not inclined to ask developers to take on
> unreasonable maintainership burden to keep respins sane and I'm not
> inclined to throwing respins over the wall and causing a bigger mess.
> -jef"dragsters are fast.. lets all drive dragsters to work"spaleta