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