long term support release

[Ralf Corsepius]

On Sun, 2008-01-27 at 19:21 -0300, Horst H. von Brand wrote:
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Sat, 2008-01-26 at 22:29 -0300, Horst H. von Brand wrote:
> > > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > > On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote:
> > > > > Horst H. von Brand wrote:

> > > > 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?

Interests collide. "RH distro developers" interests are different from
"end users" (even when putting "Aunt Tillie" aside) and "upstreams" and
development.

E.g. SELinux, NetworkManager, Pulseaudio are widely non-interesting to
me. If they worked transparently and smoothlessly, I would simply use
them and not waste a single word about them, like I do with many other
packages on a distro. Fact is, they don't work smoothless.

> > 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?
There is one machine amongst those, I would consider "exotic" and label
"strange" these days: A 1997 standard i586-notebook with f00f bug, no
usb, neomagic128-GPU, apm only. It tripped a couple of interesting
non-critical issues in Fedora (The kernel's f00f-reporting is broken,
nousb doesn't switch of ehci-hci, xorg.conf has made it hard to switch
off glx, ...).

> > > > 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. 
Yes, ... and? Everybody only uses a (comparatively small) subset of
applications, even from "Core".

> > 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. 
Yes, that's how open development of open source works. People develop in
one environment, others will use it in other environments. If code lacks
generality, then those using "strange machines", will have to report it
back.

> > @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.
Check the merge reviews. It's eye-striking.

In many cases, you see @RH's answering along the lines of "I inherited
this package from my predecessor". I could give names, but consider it
to be a matter of fairness not to do so at this place.

> > > 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's a lot of work when being systematically exercised by an
enterprise. 

In a community maintained distro it would be "demand priority driven".
People would pick up those cases which nag them and will try to address
them. Yes, it would be suboptimal, but it's still better than a bug not
having been addressed at all.

> >                     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.
> 
> No.
?!? You do not agree that fixing bugs in libraries and applications
people tripped over when running application A in situation X, often
bugs people trip over when running other applications in other
situations? 

This has happened 1000s of times and will happen 1000s of times again.
Actually, I would consider such cases to be the norm.

> > > 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.
What's strange about this? In real-life manufacturers will be sued for
"not fixing bugs in a current release" - Avoiding such situations is
called "customer care".

Customer: "Garage, when I turn on my car's head lights, the heating
starts running at full power."
Garage  : "We reported it upstream to the car's manufacturer. You might
try the next model available at your local dealer next year. Until then,
open the windows."

Ralf