On 10/23/07, William Cattey <[EMAIL PROTECTED]> 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.
+1. 9 months release 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." Again +1. 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. +1 -Bill > > ---- > > William Cattey > Linux Platform Coordinator > MIT Information Services & Technology > > N42-040M, 617-253-0140, [EMAIL PROTECTED] > 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 [email protected] https://www.redhat.com/mailman/listinfo/fedora-marketing-list
