[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Life Cycle

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.



William Cattey
Linux Platform Coordinator
MIT Information Services & Technology

N42-040M, 617-253-0140, wdc mit edu

On Oct 22, 2007, at 6:35 PM, Rodrigo Padula de Oliveira wrote:

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

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


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.

Version: GnuPG v1.4.7 (GNU/Linux)


Fedora-marketing-list mailing list
Fedora-marketing-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]