Fedora Life Cycle

[William Cattey]

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 at mit.edu
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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-marketing-list