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
Attachment:
pgpTZsRHRuKUT.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
