[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: long term support release
- From: "Horst H. von Brand" <vonbrand inf utfsm cl>
- To: Ralf Corsepius <rc040203 freenet de>
- Cc: Development discussions related to Fedora <fedora-devel-list redhat com>
- Subject: Re: long term support release
- Date: Sun, 27 Jan 2008 19:21:11 -0300
Ralf Corsepius <rc040203 freenet de> wrote:
> On Sat, 2008-01-26 at 22:29 -0300, Horst H. von Brand wrote:
> > Ralf Corsepius <rc040203 freenet de> wrote:
> > > On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote:
> > > > Horst H. von Brand wrote:
> > > I guess no reasonable _user_ wants 'bleeding-edge'.
> > I consider myself "reasonable"... but sure, the evaluation comes from
> > awfully close ;-)
> I guess your objective is "development of the distro" itself.
> My objective is application development, the distro itself is secondary
> and is a vehicle.
OK, mine too.
> > > As a developer, it's not a major problem for _me_ having to cope with a
> > > couple of issues here and there, but how do you expect "Aunt Tillie" to
> > > cope with them?
> > Perhaps Fedora isn't for her then.
> We are back to the point of questioning Fedora's target audience. As it
> currently seem to me the target audience is "RH distro developers".
If so, how is that wrong?
> > > Also, with F8 I have been confronted with so many tiny issues, which all
> > > together render productive use of Fedora close to impossible and have
> > > caused me to have doubts on the project's sanity.
> > Have you reported them?
> Many of those I could identify the cause of, many have been reported by
> others before, many have not yet been reported, ... many are not
I for one have reported many bugs for which I didn't have the foggiest idea
what the cause coukd be. And most of them got fixed (either by taking up my
report, or in course of other updates).
> > [BTW, most of the F8 timeline I was running rawhide, and I was reasonably
> > productive al throughout, except for some short glitches. So I don't buy
> > your "close to impossible to use".]
> Just to mention a few:
> - The yum on F8's DVD is broken. It produces incorrect results.
Fixed by an update? Can you use a respin?
> - The DVD's packaging only contains a subset of packages.
Complain to the DVD Forum <http://www.dvdforum.com>, they /have/ to
understand the needs of "everything and the kitchen sink" Linux
distribution install media.
> It doesn't
> allow upgrading from FC7+updates at all.
Fixed in updates/respin?
> - F7 updates had a couple of nasty packaging bugs (e.g. avahi), which
> cause the F8 upgrade process to break.
Happens, nobody is perfect.
> Another issue: the kernel.
> For me, Fedora 8 doesn't boot without carefully handcrafted boot
> parameters on 3 out of 4 machines. Aunt Tillie would never have been
> able to fix them.
Again, have you reported it? Are they in any way strange machines?
> > > Interestingly, it's not the "community-maintained packages" some seem to
> > > preferr to accuse to be of low quality, which are causing the trouble,
> > > it's the sum of issues with the "standard/default packages" which are
> > > piling up.
> > Stands to reason, the "standard/default packages" are the foundation of the
> > system.
> Yes, while this is true, consider "other packages" are equally important
> to an individual's installation.
They affect only the subset of people who use them. Sure, it is hard on the
victims, but less important overall than breakage in something shared by all.
> This is likely the cause the majority of community maintainers to be
> tending to apply different strategies on bug fixing: They often use
> their packages themselves, therefore they fix bugs inside of their
> packages themselves for all Fedoras.
They probably are in position to check/fix for /their/ Fedora, not for
other versions. To be a maintainer doesn't include having 3 or more machines
around to check other versions (today that would be F7, F8, rawhide; then
there are at least i686, x86_64 and PPC right now).
> @RH maintained "standard/default packages" on the other hand often
> appear to be maintained by people who "have been ordered to take an
> unloved job/duty".
And don't use them personally at all? Strange. Have you got any data to
support this (i.e., at the very least split of RH vs community maintainer
by package plus bugs outstanding, say, more than a month)? Besides, they
probably /do/ have access to the full range of guinea pigs.
> > > > A desktop app that crashes once in a while is not a huge problem
> > > > - and wouldn't be a problem at all if there were an option to drop back
> > > > to a more stable version.
> > > > A machine that won't boot or a device driver
> > > > that no longer talks to my hardware is.
> > > Yep, that's one subset amongst several sets of issues I am facing ;)
> > > Fortunately, these happen to be the easy cases. The really nagging ones
> > > are those, one can't identify the cause of.
> > And those get magically fixed by extending the life of a random version
> > with an understaffed crew doing on-and-off bug fixing and
> > backporting?
> In not too rare cases, yes, because backporting closes "one case" from
> the "pile of bugs".
But it is a lot of work, for very little gain.
> It could be the bug which has caused the damage in
> an individual's situation. It is the place where the "magic" happens
> which causes "magic bug fixes" to happen.
> > In my experience, they end getting fixed by moving forward.
> A bug is only fixed if it takes place in the current release.
Strange definition of bug fix.
> bugs by moving forward on "rawhide", "upstream", or "sitting bugs out"
> doesn't fix anything for the current release and doesn't help users of
> the current release.
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
[Date Prev][Date Next] [Thread Prev][Thread Next]