[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A request for more agressive updates to FC


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

Just curious. Thanks.

Steve Brenneis

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 surry net>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]