4:08 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All!!
I'm thinking about the Fedora Life Cycle and i have some conclusions:
- - 13 months is a very short life cycle time and it's a bad thing
thinking in the Fedora Marketing (I am constantly asked about it in my
lectures).
- - with this short time we cannot use Fedora in production servers. In
Brazil we have BIG FEDORA CASES and it's a major concern of Brazilian TI
Managers.
- - many of linux distributions has more than 13 months of life cycle
So,how can we extend that life cycle to increase for at least 2 years by
release?
IMHO, we should do this!!
Rodrigo Padula de Oliveira
http://www.projetofedora.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHRFdPg3HAC1vlg4RAkwEAJ9yCrxDLPzwgAaoyMjMSqMJpHPEVQCgn6U3
84Tlew5BXAEyNvGZWVa7o7w=
=T5JA
-----END PGP SIGNATURE-----
4:19 p.m.
On Mon, 22 Oct 2007 19:08:45 -0200
Rodrigo Padula de Oliveira <rodrigopadula(a)projetofedora.org> wrote:
I'm thinking about the Fedora Life Cycle and i have some
conclusions:
- - 13 months is a very short life cycle time and it's a bad thing
thinking in the Fedora Marketing (I am constantly asked about it in my
lectures).
- - with this short time we cannot use Fedora in production servers.
In Brazil we have BIG FEDORA CASES and it's a major concern of
Brazilian TI Managers.
- - many of linux distributions has more than 13 months of life cycle
So,how can we extend that life cycle to increase for at least 2 years
by release?
IMHO, we should do this!!
No, we shouldn't. When 13 months is not long enough for you, we have
wonderful options for long term support. RHEL and CentOS. They're
based on Fedora but have a longer life span (7 years) and a slower
release cycle (every 2~ years). With these options, why in the world
would we want to put that effort into Fedora itself?
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
4:42 p.m.
On 10/22/07, jkeating wrote:
No, we shouldn't. When 13 months is not long enough for you, we
have
wonderful options for long term support. RHEL and CentOS. They're
based on Fedora but have a longer life span (7 years) and a slower
release cycle (every 2~ years).
perhaps someone could detail a bit how to use a Fedora box with EPEL
repositories.
Chitlesh
--
http://clunixchit.blogspot.com
4:50 p.m.
On Mon, 22 Oct 2007 23:42:13 +0200
"Chitlesh GOORAH" <chitlesh(a)fedoraproject.org> wrote:
perhaps someone could detail a bit how to use a Fedora box with EPEL
repositories.
You mean a RHEL or CentOS box with EPEL repositories?
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
4:21 p.m.
On Mon, 22 Oct 2007, Rodrigo Padula de Oliveira wrote:
I'm thinking about the Fedora Life Cycle and i have some
conclusions:
- - 13 months is a very short life cycle time and it's a bad thing
thinking in the Fedora Marketing (I am constantly asked about it in my
lectures).
- - with this short time we cannot use Fedora in production servers. In
Brazil we have BIG FEDORA CASES and it's a major concern of Brazilian TI
Managers.
- - many of linux distributions has more than 13 months of life cycle
So,how can we extend that life cycle to increase for at least 2 years by
release?
IMHO, we should do this!!
Appreciate the enthusiasm, Rodrigo, but again:
The goal of Fedora is rapid innovation.
The goal of RHEL/Centos is long-term supportability.
These two goals tend to be mutually exclusive.
The Fedora Legacy project tried to maintain Fedora releases for a longer
period of time. Legacy failed because no one volunteered to support it.
Why? Because they were all using Centos.
IMHO, it's far more interesting -- and useful -- to make upgrades work
flawlessly.
--g
--
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"
3:55 p.m.
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.
5:15 p.m.
On Mon, 22 Oct 2007, Gian Paolo Mureddu wrote:
> IMHO, it's far more interesting -- and useful -- to make
upgrades work
> flawlessly.
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.
The current thinking (which I agree with) favors Anaconda-based upgrading
with a new and improved online component, rather than yum-based upgrading.
Take a look at the following feature proposal:
http://fedoraproject.org/wiki/Features/PreUpgrade
Think about your use cases in the context of this feature, and maybe add
any comments you have to the wiki page itself.
--g
--
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"
6:16 p.m.
Greg DeKoenigsberg escribió:
On Mon, 22 Oct 2007, Gian Paolo Mureddu wrote:
>> IMHO, it's far more interesting -- and useful -- to make upgrades
>> work flawlessly.
>
> 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.
The current thinking (which I agree with) favors Anaconda-based
upgrading with a new and improved online component, rather than
yum-based upgrading. Take a look at the following feature proposal:
http://fedoraproject.org/wiki/Features/PreUpgrade
Think about your use cases in the context of this feature, and maybe
add any comments you have to the wiki page itself.
--g
Indeed, what I have thought of is /primarily/ for Anaconda. Yum could
also be involved, but first one thing at a time, a better finer control
over the upgrade from within Anaconda for tasks where GUI does make
sense for this would be a priority before making "networked upgrades"
work with Yum. Simple stuff like being able to "choose" which users you
want to migrate, nuke everything in the disk, except from chosen
directories (/home/{user1,user2...n}, /root, /usr/local, etc), allowing
the distribution to first get in place all the files and configurations
it needs, THEN modify whatever files with only the information
"salvaged" from the previous one. Getting that to be as clean and
painless as possible should be a priority for Anaconda upgrading. Will
take a look at the Wiki and see what other ideas can I toss around.
8:15 p.m.
On Mon, 22 Oct 2007 18:15:37 -0400 (EDT)
Greg DeKoenigsberg <gdk(a)redhat.com> wrote:
The current thinking (which I agree with) favors Anaconda-based
upgrading with a new and improved online component, rather than
yum-based upgrading. Take a look at the following feature proposal:
And since anaconda /uses/ yum it's like having a smart wrapper around a
yum upgrade to handle all the niggly details.
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
5:35 p.m.
-----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-----
5:56 p.m.
man, 22 10 2007 kl. 20:35 -0200, skrev Rodrigo Padula de Oliveira:
-----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 !!
They knew our release schedule when they deployed right? So why is it a
problem now and why are you basically demanding that we redesign a
successful model to avoid your problem given that you were warned in
advance.
I would suggest that if SERPRO needs a longer cycle they could work with
Fedora to branch a release like the upcoming Fedora 8 and volunteer to
do all the maintance work to give it the lifecycle they need. I'm sure
such an investment would be considered valuable by webhosts and the
likes.
Alternatively you could go with CentOS which is built on Fedora but with
a 7 year life span and release major releases every ~2 years. That seems
more suitable for your needs.
Fedora is a rapidly evolving platform, we depend and commit to the 6
month cycle with a reasonable lifecycle giving us that.
The only thing we can do is increase testing of the upgrade process to
make it as painfree for you as possible, but we'll need and value your
help in doing this. More hands on deck is always good.
Your friendly neighborhood QA monkey
5:58 p.m.
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(a)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-----
--
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
8:17 p.m.
On Mon, 22 Oct 2007 18:58:01 -0400
William Cattey <wdc(a)MIT.EDU> wrote:
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.
RHEL regularly enables new hardware in the quarterlyish updates. You
aren't stuck with two year old hardware sets.
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
8:57 p.m.
Actually, I'm still working the kernel bug that broke the VESA driver
that we opened when the Dell 745 first shipped. I believe that
desktop gets EOLed in the next month or so. The Disk driver to SATA
get off of BIOS compatibility mode came two quarters into the
machine's life cycle. The RHEL 5 driver update to get rid of the
SATA timeouts on start-up won't ship till after the machine is gone
at this rate.
So, yes quarterly updates should, in theory solve the problem.
In practice, they are necessary, but not sufficient.
-Bill
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
N42-040M, 617-253-0140, wdc(a)mit.edu
http://web.mit.edu/wdc/www/
On Oct 22, 2007, at 9:17 PM, jkeating wrote:
On Mon, 22 Oct 2007 18:58:01 -0400
William Cattey <wdc(a)MIT.EDU> wrote:
> 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.
RHEL regularly enables new hardware in the quarterlyish updates. You
aren't stuck with two year old hardware sets.
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/
jkeating.j2solutions.pub)
--
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
9:32 p.m.
On 10/23/2007 04:17 AM, jkeating wrote:
On Mon, 22 Oct 2007 18:58:01 -0400
William Cattey <wdc(a)MIT.EDU> wrote:
> 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.
>
RHEL regularly enables new hardware in the quarterlyish updates. You
aren't stuck with two year old hardware sets.
We are kind of getting away with the list topic, but FWIW, I've
bought - more like an experimental playground - three boxes based on
Asus M2N-MX motherboards (el cheapo entry-level nVidia Corporation MCP61
+ nVidia Corporation GeForce 6100 nForce 430 graphics controller). I had
a hell of a time trying to make those work in Centos 4 and 5. (Yes, I
know I could pay $$$$ for a special contract and have a dedicated team
implement whatever I need, or that I could look over the HCL before
buying. And I also know most of what "enterprise" mean, including in
terms of hardware. That's not the point for the below lines.)
In C4 it was impossible to start the installer, no matter what
options we've tried (however, the box kind of worked OK after I moved
the hard disk to another computer, do the install and transfer the disk
back).
In C5 it was more than funny to observe how the box would come up
with a different MAC address after every reboot (until the network
driver available on NVidia's site was used). After that, it took us half
an hour to fiddle with xorg.conf to configure the display settings for a
Samsung 17" TFT display (*-config-display failed with trumpets in
generating a functional config). Finally we gave up fiddling and before
throwing the box thru the balcony's window we switched to the NVidia
proprietary driver. We haven't yet been able to make the box not lock if
USB is enabled in BIOS & sound is still not functional, I still have to
backport a newer alsa rpm. The irony is that replacing the CRT monitor
with a TFT (and creating the new xorg.conf) was much easier in C4 than
in C5.
OTOH, F7 worked almost like a breeze on the same hardware. Except
for video: once again I had to fiddle directly with xorg.conf adding a
custom Modeline, otherwise the image was shifted 5" to the right and 1"
narrower. And funniest of all, after making everything work (or so I
thought) and having the exact setup I wanted after rebooting in runlevel
7 with Gnome as Desktop Environment, in the very moment I selected KDE
and logged in as regular user, the image shifted again 5" to the right,
as if I did not setup the video at all. Go figure...
Bottom line, lots of people do lots of work, but for _recent_
hardware there still are steps to be performed. And even with the
efforts put in their quarterly updates, I would say RHEL lags an year
behind hardware that is available in the street. And as someone who
started learning linux by using RH 4.2, I am sad to say it, but I feel
that other distros (hint: knoppix/ubuntu) cope better with this aspect.
8:54 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So.... if you need Stability... use Red Hat or CENTOS. (HELLO SERPRO..
CHANGE YOUR GNU/LINUX DISTRIBUTION!!!!!)
If you are interested to test software and innovation(six on six months)
for when it will be stable for Red Hat and CentOS.. use fedora!!!!!
Great Marketing issue!!!
You are saying that in your lectures ?? It's a negative marketing!
If i say that bull..... here, all Brazilian fedora users will be use
UBUNTU! So.. we won't have users to test these INNOVATIONS!
Rodrigo Padula
Frustrated Brazilian Fedora Ambassador
http://www.projetofedora.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHVQ/Pg3HAC1vlg4RAj3QAJ9UL4JHLWopAxjaxy636LIJA9xpswCdHZT1
qun2L1DyzIX7u2ANZtD5Twk=
=YW1Z
-----END PGP SIGNATURE-----
9:31 p.m.
Rodrigo Padula de Oliveira wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So.... if you need Stability... use Red Hat or CENTOS. (HELLO SERPRO..
CHANGE YOUR GNU/LINUX DISTRIBUTION!!!!!)
If you are interested to test software and innovation(six on six months)
for when it will be stable for Red Hat and CentOS.. use fedora!!!!!
Great Marketing issue!!!
You are saying that in your lectures ?? It's a negative marketing!
If i say that bull..... here, all Brazilian fedora users will be use
UBUNTU! So.. we won't have users to test these INNOVATIONS!
Rodrigo Padula
Frustrated Brazilian Fedora Ambassador
http://www.projetofedora.org
All I can say is WOW.
None of this is new, in fact some of it is very old. The life cycle of
Fedora has not gotten any shorter in fact it is longer now than it was
in the past. I hate to sound rude, but I want to ask "What Brazilian
cave have you been living in?" There is now a one month overlap between
every two releases this is more than we had before.
Remember this is open source software. If YOU want a longer
support/patch/backport cycle YOU are more than welcome to offer such a
thing. As a matter of fact if YOU would like to YOU could even turn it
in to a multi-million dollar business.
There are many things to be frustrated about as an ambassador, you are
not unique in being frustrated. However if you had any part in SERPRO
choosing Fedora you should not be frustrated you should be embarrassed.
Robert 'Bob' Jensen
Fedora Unity Project
http://fedoraunity.org/
7:25 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert 'Bob' Jensen escreveu:
"What Brazilian cave have you been living in?"
Robert 'Bob' Jensen
Fedora Unity Project
http://fedoraunity.org/
Ohhh I was not in a cave. I am an Indian and I live in the jungle named
AMAZONIA!
I will cry! lol
Rodrigo Padula de Oliveira
Welcome to the Jungle!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHehJPg3HAC1vlg4RApbsAKCAjA1tBhrP9CoIIgJFBpQiEjyrsACeJ8Vr
Tco+1gJhLB7Zb5OCx7dcpVw=
=uYH7
-----END PGP SIGNATURE-----
12:06 a.m.
On 10/23/07, William Cattey <wdc(a)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
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, wdc(a)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-----
>
> --
1:04 a.m.
Rodrigo Padula de Oliveira wrote:
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 !!
But with a life cycle of 13 months, why not update yearly?
It involves planning and a lot of work! it's not that simple!!!!!
Maybe you read about the proposal to change the development process and
replace test 1,2,3 with alpha, beta, release candidate. Maybe planning
the update may start in advance, around RC?
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.
This is desktop use, seriously, for desktop would you want to use less
than the latest version of your applications? Would you use *now*
Firefox 1.5, OpenOffice.org 2.2.1, GIMP 2.2 or Inkscape 0.44?
--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro
5:35 a.m.
Rodrigo Padula de Oliveira wrote:
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!!!!!
They don't have to upgrade just because we have a new release. They can
upgrade every 13 months or so instead. Just something I thought I would
highlight better.
Rahul
7:34 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rahul Sundaram escreveu:
Rodrigo Padula de Oliveira wrote:
> 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!!!!!
>
They don't have to upgrade just because we have a new release. They can
upgrade every 13 months or so instead. Just something I thought I would
highlight better.
And They can not enjoy the innovations?
Let's go!
- - Fedora is released
- - 1 or 2 months packing and releasing new and necessaries packages
versions ( now we have 11 months).
- - 1 or 2 months planning, studying the impacts, creating the migration
plan and applying it(now we have 9 months)
- - ohhhh in 9 months we have to do this again
- - so, we will use CENTOS or DEBIAN.
That is the problem! Year by year migrating all fedora systems to the
new version!
Rahul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHepAPg3HAC1vlg4RAmNWAJ4wEXucqCmdkD32H0SDM1yicUeMBACfXYJt
Hh0A4qFIG/7BE1nTdFBI5+s=
=LIx1
-----END PGP SIGNATURE-----
6:40 a.m.
Rodrigo Padula de Oliveira wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rahul Sundaram escreveu:
> Rodrigo Padula de Oliveira wrote:
>
>> 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!!!!!
>>
> They don't have to upgrade just because we have a new release. They can
> upgrade every 13 months or so instead. Just something I thought I would
> highlight better.
And They can not enjoy the innovations?
Not sure what you mean. You cannot get both the latest software at all
times and want a long release cycle at the same time. It doesn't work
that way.
Rahul
8:59 a.m.
Dude, we had already experimented a 9 months release cycle and the
experiment was a complete failure. Fedora Legacy closed its door
because it lacked contributors.
Current release schedule perfectly fits FedoraProject and community,
and nobody would be gainst extending support, we're just lacking
contributions
If you want a longer support cycle, feel free to revive Fedora Legacy
or just use CentOS.
So, come with a concrete suggestion and we'll listen you, but whining
on the m-l is NOT an option.
8:54 a.m.
2007/10/23, Rodrigo Padula de Oliveira <rodrigopadula(a)projetofedora.org>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rahul Sundaram escreveu:
> Rodrigo Padula de Oliveira wrote:
>
>> 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!!!!!
>>
>
> They don't have to upgrade just because we have a new release. They can
> upgrade every 13 months or so instead. Just something I thought I would
> highlight better.
And They can not enjoy the innovations?
Let's go!
- - Fedora is released
- - 1 or 2 months packing and releasing new and necessaries packages
versions ( now we have 11 months).
- - 1 or 2 months planning, studying the impacts, creating the migration
plan and applying it(now we have 9 months)
- - ohhhh in 9 months we have to do this again
- - so, we will use CENTOS or DEBIAN.
1. Requirement Analysis
2. Evalution of alternatives
3. Pick the distribution best suited for the task at hand and start planning
So you just figured out fedora doesent meet your or your customers
requirements and you are not a member of the intended audience with
running a production server with fedora then fine... there are enough
alternatives better suited for the task. just proposing that fedora
should be yet another distribution that moves very slowly (there are
enough of those available) isnt very productive.
regards,
Rudolf Kastl
That is the problem! Year by year migrating all fedora systems to the
new version!
>
> Rahul
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHepAPg3HAC1vlg4RAmNWAJ4wEXucqCmdkD32H0SDM1yicUeMBACfXYJt
Hh0A4qFIG/7BE1nTdFBI5+s=
=LIx1
-----END PGP SIGNATURE-----
--
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
11:10 a.m.
On Tue, Oct 23, 2007 at 10:34:08AM -0200, Rodrigo Padula de Oliveira wrote:
Let's go!
- - Fedora is released
- - 1 or 2 months packing and releasing new and necessaries packages
versions ( now we have 11 months).
- - 1 or 2 months planning, studying the impacts, creating the migration
plan and applying it(now we have 9 months)
- - ohhhh in 9 months we have to do this again
- - so, we will use CENTOS or DEBIAN.
That is the problem! Year by year migrating all fedora systems to the
new version!
Hi Rodrigo,
I understand the frustration you feel in this tension between the benefits
of a fast-moving rate of innovation and the need many organizations have to
not be constantly upgrading all of their machines. You are not alone in
feeling torn between two choices, neither of which seem optimal for you. I
am sure there are a lot of other organizations that are in the same
position.
I also note with admiration that you are clearly a person with a lot of
energy and a sincere passion for the Fedora Project.
Therefore I have a few questions for you. How large an organization is
SERPRO? What is its annual budget, roughly? And how many other large
organizations are you aware of that have similar concerns?
The reason I ask is that it seems to me that if an organization with
thousands of employees really depends on Fedora for its daily operations,
and if that organization would greatly benefit from an increased support
cycle for Fedora, then it might easily be worth it for that organization to
hire a small handful of developers specifically tasked with continuing the
maintenance of the distro for a period of time after the Fedora Project has
ceased to support it. And if this might be a worthwhile investment for
SERPRO, perhaps it would also be worthwhile for a few other large
organizations in similar situations. Given a handful of organizations, each
sponsoring a handful of developers, it seems to me you could easily
accomplish what you desire, and effectively revive something like the Fedora
Legacy project. Skip every odd (or even) numbered release, and concentrate
on providing only the most critical updates for your supported release for
one additional year, giving you a total supported lifespan of ~2 years, and
you'd never be supporting more than two releases at once.
Of course, it would take a person with a lot of energy and a sincere passion
for Fedora to organize such an effort, and to convince a few organizations
like SERPRO that this would be a cost effective way to solve their problem.
Perhaps you know such a person? :)
cheers,
- Paul
--
Paul Stauffer <paulds(a)bu.edu>
Manager of Research Computing
Computer Science Department
Boston University
6:43 p.m.
Greg DeKoenigsberg wrote:
IMHO, it's far more interesting -- and useful -- to make upgrades
work
flawlessly.
+1
--
Eric Feldhusen
Network Administrator http://www.remc1.org
eric(a)remc1.org
PO Box 270 (906) 482-4520 x239
809 Hecla St (906) 482-5031 fax
Hancock, MI 49930 (906) 370 6202 mobile
5:55 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So, we have to put in our site:
- - Get CentOS
- - Buy RHEL
Obs: We can not resolve your problem, if you need INNOVATION and want to
be a "beta" tester for Red Hat and Centos, GET FEDORA!!!
I will have a lecture today and I do not know what I will say. I lost my
arguments!
I'm stopping here, else I will download the CENTOS and i will go to the
Centos Project.
Thanks all for the clarifications.....
Rodrigo Padula
Brazilian Fedora/CentOS Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHdMhPg3HAC1vlg4RAsfiAKDIhC8RENXCjnlNWgKRjnCFVJLscgCdGLZD
DUSE2nXD+iQbidkgPSrDgFc=
=MT9u
-----END PGP SIGNATURE-----
11:28 p.m.
Hi,
IMHO, I really don't think we should do this, most people use Fedora for
personal computer.
I am one of the people who like my system to be up-to-date and use the most
recent technologies.
You can still use Fedora 6 if you want, I don't think there's any problem
with that :)
Oh, BTW, isn't the life cycle now 6 months? Last release (Fedora 7) was in
May, and Fedora 8 will be released in November, and that is what most
popular distros do.
Cheers!
On 10/23/07, Rodrigo Padula de Oliveira <rodrigopadula(a)projetofedora.org>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All!!
I'm thinking about the Fedora Life Cycle and i have some conclusions:
- - 13 months is a very short life cycle time and it's a bad thing
thinking in the Fedora Marketing (I am constantly asked about it in my
lectures).
- - with this short time we cannot use Fedora in production servers. In
Brazil we have BIG FEDORA CASES and it's a major concern of Brazilian TI
Managers.
- - many of linux distributions has more than 13 months of life cycle
So,how can we extend that life cycle to increase for at least 2 years by
release?
IMHO, we should do this!!
Rodrigo Padula de Oliveira
http://www.projetofedora.org
--
Laith Juwaidah
ljuwaidah(a)gmail.com
http://www.ljuwaidah.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHHRFdPg3HAC1vlg4RAkwEAJ9yCrxDLPzwgAaoyMjMSqMJpHPEVQCgn6U3
84Tlew5BXAEyNvGZWVa7o7w=
=T5JA
-----END PGP SIGNATURE-----
--
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
12:01 a.m.
On Tue, 2007-10-23 at 08:28 +0400, Laith Juwaidah wrote:
Oh, BTW, isn't the life cycle now 6 months? Last release (Fedora
7)
was in May, and Fedora 8 will be released in November, and that is
what most popular distros do.
That is the release cycle. I guess the life cycle is the time for which
the release is supported.
--
Best Regards,
Aravind
http://www.aravind.name
2:04 a.m.
Oh, thanks for the clarification :)
On 10/23/07, Aravind Seshadri <aravind(a)aravind.name> wrote:
On Tue, 2007-10-23 at 08:28 +0400, Laith Juwaidah wrote:
> Oh, BTW, isn't the life cycle now 6 months? Last release (Fedora 7)
> was in May, and Fedora 8 will be released in November, and that is
> what most popular distros do.
>
That is the release cycle. I guess the life cycle is the time for which
the release is supported.
--
Best Regards,
Aravind
http://www.aravind.name
--
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
--
Laith Juwaidah
ljuwaidah(a)gmail.com
http://www.ljuwaidah.com
6023
days inactive
6024
days old
marketing@lists.fedoraproject.org
30 comments
18 participants
participants (18)
-
Aravind Seshadri -
Chitlesh GOORAH -
David Nielsen -
Eric Feldhusen -
Gain Paolo Mureddu -
Greg DeKoenigsberg -
H. Guémar -
Imtiaz Rahi -
Jesse Keating -
Laith Juwaidah -
Manuel Wolfshant -
Nicu Buculei -
Paul Stauffer -
Rahul Sundaram -
Robert 'Bob' Jensen -
Rodrigo Padula de Oliveira -
Rudolf Kastl -
William Cattey