A request for more agressive updates to FC

[Steve Brenneis]

Carlos,

Could you expand on what you mean by GNOME in FC2 SMB being totally
broken? Symptoms, etc.? I'm interested because that is my impression as
well. I haven't posted much about that here (avoiding troll branding),
but I would like to know what you are encountering. Maybe we can fix
some of them together.

Some of the issues I have with GNOME seem to have been there in FC1 as
well.

Just curious. Thanks.

Steve Brenneis
http://myorb.sourceforge.net

On Mon, 2004-07-26 at 19:58, Carlos Rodrigues wrote:
> Hi!
> 
> This will be a bit long, so if you don't have anything better to do,
> please bear with me.
> 
> Since the days of Red Hat Linux 5.0, when I started using Linux, I have
> followed a ritual with every new release. The ritual consists in looking
> around for stuff that used to work and is now broken. Fortunately, the
> server related stuff seems to be immune to obvious regressions, but that
> cannot be said of desktop related stuff. Some of these regressions are
> easy to fix (and I sometimes fix them myself) but the fixes have to wait
> for the next release, where other regressions pop up... This is a never
> ending cycle.
> 
> In the days of Red Hat Linux, the situation was much worse, since the
> only updates that appeared were security fixes (which are good), bug fix
> updates were as rare as water in the desert. But today we are no much
> better.
> 
> So, what I'm saying is that there should be a more agressive update
> policy to Fedora Core, new packages should go into updates-testing and
> then updates except if there is a good reason not to. Let's have gaim as
> an example, it is a piece of software with many shortcomings and which
> gets better with every release. It's also a non intrusive package, and
> so the new gaim that pops up in updates every couple of weeks is a
> welcomed update. However, there is a nut package in "development" that
> fixes some configuration file ownership stuff that stays there, although
> it has no other change from the version in FC2.
> 
> Stuff should never go into "development" unless there is a strong
> reason, meaning "it breaks other packages", "it requires tons of
> dependency updates, some of which possibly beaking other packages" or
> "it changes basic stuff in the distro, like how initialization is done,
> security is handled". FC2 should have a more evolutionary approach,
> stuff like mozilla-1.7 should go directly into updates-testing. New FC
> releases should mean big stuff like SELinux, kernel 2.6 and the likes,
> meanwhile FC should be as close to development as possible (without that
> big stuff).
> 
> Basically I'm saying that FC should be "development" without the
> dangerous suff. After all this is a distro for hobbyists which like to
> be as close to the bleeding-edge as possible, without actually bleeding.
> 
> Why do I say this? Because I feel that once a release is out, almost
> everybody moves its attention onto the next one and forgets about us
> folks. FC should not be the absolute bleeding edge, but it shouldn't
> also be RHEL... evolution is needed. This would allow to squash bugs
> earlier, meaning getting to a stable desktop (as in not crashing or
> buggy, not feature-frozen) faster.
> 
> I'm kind of sick of being between a rock and a hard place, either I use
> a bleeding-edge distro and spend all my time bleeding or I use a over
> conservative distro and never get new features... Am I totally clueless?
> 
> Well, to be true, the same thing that I say above can be accomplished by 
> turning "updates-testing" into some sort of half-way between FC and 
> "development", more dynamic but not as risky.
> 
> Carlos Rodrigues
> 
> 
> PS: I was prompted into this because in FC2 smb with GNOME is totally
> broken (amongst other things), and even if a GNOME 2.6.2 gets out I know
> that it will never come out, FC3 will bring 2.8 and new stuff will
> break. It's actually funny (in a bad way) that GNOME gets released as
> frequently as FC, which means we always get a .0 release and not the
> following bug fixes... damn!
-- 
Steve Brenneis <sbrenneis at surry.net>