On 10/23/07, William Cattey <wdc@mit.edu> wrote:

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@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-----
>
> --