I too have been agonizing over product cycles.
Enterprise is stable, but on the desktop often does not get critical
device drivers until too late in the life cycle of hardware. And the
hardware I'm looking at is not the fancy gamer platform. It is the
workhorse enterprise desktop platform like Dell Optiplex.
Furthermore Enterprise does not get certain new apps quite soon
enough. For example OpenOffice 2.0 and Firefox 2.0. (I have had
some very interesting conversations with some of the folks who were
majorly involved in the decisions about roll-out of apps, and I
appreciate the sensible rationale expressed for the path taken.
Nevertheless, I took the heat when the majority of the world moved on
to a version of the app not supported by Red Hat. Doing an mit-only
early deploy of an app is something we're investigating, but it too
has issues.)
Fedora would be an attractive alternative except that it is too
volatile. Indeed many difficult release engineering problems go away
with a 1 year release and 2 year life cycle.
EPEL is an interesting and possibly helpful alternative because it
gets some of the interesting apps from Fedora going on Enterprise.
Unfortunately, that doesn't solve the, "I can't buy the desktops on
sale this year because the disk driver, and/or the ethernet driver
and/or the video driver won't be back ported from Fedora to
Enterprise until the machines on sale this year are no longer
available."
Jesse Keating and Greg DeKoeningsberg say that stability is what RHEL
and CentOS are for, and that it's inappropriate to try and move
Fedora away from the benefits of the current state -- great
responsiveness, and tractable release engineering aspects for updates.
Indeed if the problem is framed, "stability versus innovation" the
two aspects are in conflict. My question is:
How can use cases for hardware available now, requiring a few
critical apps needing to be ported now be accommodated? Neither
Enterprise nor Fedora fits well enough at the present time.
-Bill
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
N42-040M, 617-253-0140, wdc@xxxxxxx
http://web.mit.edu/wdc/www/
On Oct 22, 2007, at 6:35 PM, Rodrigo Padula de Oliveira wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
By example i will use the biggest Brazilian Fedora Case.
SERPRO (Brazilian Government IT Department) has more than 8.000
desktop
stations and several servers using Fedora inside spread in 26
Brazilian
States.
Do you have any idea of what i'm talking about ????
How can they update it every six month?? It's a craziness !!
It involves planning and a lot of work! it's not that simple!!!!!
IMHO the release and life cycle must be increased!
RELEASE -> 1 per year
LIFE CYCLE -> 2 years
It'd reduce the Artwork, Free Media, Marketing, Translation,
Documentation and Packing issues.
.... and mirrors, band use and others things!!!!!!!!!!
Best regards!
Rodrigo Padula de Oliveira
Gian Paolo Mureddu escreveu:
Greg DeKoenigsberg escribió:
IMHO, it's far more interesting -- and useful -- to make upgrades
work
flawlessly.
--g
I couldn't agree more with you on this! Theoretically upgrades
shouldn't
need to be too difficult, heck you can sort of do them "by hand"
if you
know what files you need and more specifically, what /parts/ of the
files are needed... I'm specifically talking about passwd, shadow,
group
& gshadow, and paths such as /home, /root, etc. Of course there's
also
the "individual applications' config files, which can still be worked
out. I've been thinking about this and it shouldn't be too difficult,
but have been told time and time again that such a feat is
impractical
and nonsensical in the long run. I'm not convinced, but, then
again it
could be made possible for an automatic upgrade process to also be
clean
enough... I'll give it a bit more thought and maybe post an RFE on
Bgzilla about the issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHSWtPg3HAC1vlg4RAgNJAJoD9ulktv1IFbej0mafvHdxxgcZEwCbBkBA
OqO1pmAwzKEsKS0v+25HonQ=
=FQbb
-----END PGP SIGNATURE-----
--
Fedora-marketing-list mailing list
Fedora-marketing-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
--
Fedora-marketing-list mailing list
Fedora-marketing-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
