On Thursday 28 June 2007 14:05:41 Olivier Galibert wrote:
Well, from my point of view from a part-time sysadmin in a lab with
200+ computers to handle, the two main problems are:
- 6-months release cycle, with reinstall needed
- loss of Core
I'm going to expand on that a little. My users need an installation
which is reasonably up-to-date (recent firefox and openoffice for a
start) and which does not require them to change their habits too
much. I need an installation I can put semi-automatically on a
computer with a minimum of handholding and which includes 99% of what
all my users will ever need (hard drives are cheaper than my time).
One solution is to have a local package repository with a good
coverage, and a boot+kickstart that does an everything install of that
repository, configures things locally, but still asks for things like
partitioning, keyboard type, ip addresses or root password. And
points yum at the repository for updates.
Then the question becomes "what do I put in the repository", "how do I
update it", and "how often do I have to go back in front of the
computer to do a full reinstall".
For the first two questions, "Core" was a godsend, and "Prime" is
nowhere near it. Core was a set of packages you could install without
conflicts in in reasonable space (12G for fc5 on amd64) and, once
added a small number of packages from extras, pbone and local compiles
it provided enough choice to my users to be happy (decent KDE, decent
Gnome, other less-known wms) and do their work. Prime is a live-cd,
hence much smaller no matter what happens, which is already talking
about removing KDE, and from which is rather annoying to extract a
usable repository base.
Also Core had specific updates which also did not conflict and merging
them in was relatively easy.
I think you need to look closer. Prime went away around Test2 perhaps. Now
there is the "Fedora" spin, which isn't a LiveCD at all, it's in fact
very
close to what "Core" used to be.
As for updates, I'm really not sure why you don't mirror the updates in their
entirety so that not only what you install, but what your users may install
after the fact will be able to be updated. Yes we've had some broken deps in
F7 updates thus far, but we're working to shore up those gaps in the tools.
Now I'm going to have to find a way to make a list of packages we
want
in the repository and ensure they don't conflict and cover what my
users need. "Not happy" doesn't even begin to cover it.
As stated, look at the Fedora spin.
Oh, before you start saying that I should give my users the choice
of
what to install, don't forget two things:
- most of them don't *want* to choose, they have other things to do
with their lives, they'd just like to have what they need when they
need it
- only 15-20% of the computers are desktop, rest is servers of one
kind or another
And on top of that, you add the 6-months release cycle. Let's see
what it gives, for, say Fedora 7:
- june 2007, f7 is out. Wait for it to stabilize, give it two months
That's just silly and a waste of time.
- august 2007, try to build a working installation repository and
local configuration, that's easily going to take a month since it's
definitively not the only thing one has to do
- september 2007, install f7 on the desktop of 2-3 volunteers,give
them some time to find out all that's missing
- october 2007, all the missing packages have been added, the kinks
fixed, start installing f7 on some servers (secondary but used file
server, things like that). See how it goes.
Complete hyperbole. Start with Fedora spin, it's probably exactly what you
want. Could have that done in early July.
- november 2007, f8 is out, the installation is already becoming
obsolete
- december 2007, several emails with lkml/autofs/whatever later the
kinks are out on the server installs and scsi, nfs, autofs work
correctly again. Start installing on more servers, using the winter
vacations in order not to be too blocking
- january 2008, start installing on the desktops. Add the missing
packages the users find out.
- february 2008, reinstall the clusters (yes, plural), fight with
oscar until it behaves
- april 2008, f9 is out
- june 2008, f7 is EOLed, no more updates, including security
At fc3 or fc5 time, the delay before eol-ing was two years and not
one, and the presence of core made the "I'm missing a package" kinks
much rarer. It *was* annoying, but less.
It was /not/ 2 years. FC3 went EOL when FC5 Test2 came out. There was
Legacy, but that never really lived up to what I promised. Now we've made
the "official" lifespan even longer than before. A month's time to prepare
for a new release + 12~ months of updates is pretty reasonable. Anything
longer and you really are looking at RHEL like timelines.
--
Jesse Keating
Release Engineer: Fedora