Fedora Life Cycle
imtiaz.rahi at gmail.com
Tue Oct 23 05:06:44 UTC 2007
On 10/23/07, William Cattey <wdc at 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.
+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
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.
> William Cattey
> Linux Platform Coordinator
> MIT Information Services & Technology
> N42-040M, 617-253-0140, wdc at mit.edu
> 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-----
> > --
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the marketing