<div>On 10/23/07, William Cattey <<a href="mailto:wdc@mit.edu">wdc@mit.edu</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> +1. 9 months release cycle. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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."</blockquote> <div> Again +1. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> +1 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> -Bill ---- William Cattey Linux Platform Coordinator MIT Information Services & Technology N42-040M, 617-253-0140, <a href="mailto:wdc@mit.edu">wdc@mit.edu</a> <a href="http://web.mit.edu/wdc/www/"> http://web.mit.edu/wdc/www/</a> 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----- > > -- </blockquote></div>