Kevin Kofler wrote:
Bradley Baetz wrote:
Why is waiting for a new feature for 3 months too long?
Because the user has work to do which requires the new feature.
Sometimes, sure. But (again excluding new hardware) how often does that
happen?
Excluding support for new hardware, if you want a bleeding edge feature
run rawhide.
If you want a conservative distro, run CentOS.
Theres a difference between a conservative distro that only enables
tried and tested features and brings releases every 18 months and a
distro like fedora that adds new bleeding edge features and does
frequent releases.
But the difference that I'm talking about is the difference between what
happens during a particular release. If the only difference between a
stable release and rawhide is for application rewrites, then all users
miss out.
I use Fedora because of the first part, but I'm going overseas in a few
days and don't plan to upgrade my laptop until I stop travelling because
of the second.
I want the latest and greatest new version, as long as it:
* understands all the configuration settings from the previous version,
* does not remove any features (or render them so buggy as to make them
effectively useless) from the previous version.
But how do you know that its buggy? updates-testing helps, but some bugs
aren't immediately visible, or only happen in certain cases.
In the case of KDE, upgrades of the N.n -> N.n+1 type (e.g. 4.0->4.1)
basically fit that description, upgrades of the N.n->N+1.m type (e.g.
3.5->4.0) don't. I don't know how it is for other packages, but that's
precisely why this has to be the maintainer's call, they are the ones who
know such things best.
I don't use KDE, but KDE is a bit different in that its a collection of
programs that are pushed as a set, which isn't the regular situation.
Major rewrites should only go into new Fedora releases, but I don't see "add
feature X" type upgrades as a problem.
The problem is that very few features are standalone and no risk. I'm
not suggesting that Fedora says 'no version updates in stable releases',
I'm just saying that package maintainers should think about the
potential risks a bit more.
I don't think its unreasonable for a user, once they've installed a
distribution, to keep using it and its stable updates without wireless
breaking (multiple times), printers to stop working, NM to stop working,
or gphoto to stop talking to my camera.
That sucks indeed. One of the issues is that the kernel updates usually get
pushed even if they have a lot of negative feedback for common hardware
like iwl4965. Maybe something can be done there. But then it becomes an act
of balancing the hardware for which the kernel fixes things vs. the
hardware for which it breaks things.
Sure, but the maintainer can't balance the hardware thats fixed vs the
hardware thats broken because the maintainer doesn't *know* which
hardware will be broken by an update.
(Although some of my examples were caused when new hardware support was
added, I did exclude hardware support from a 'feature' earlier)
On the other hand, while regressions tend to annoy users a lot (I know I
hate them), objectively considered, a regression is not as bad as an
unfixed bug, because one can always revert to the working version, whereas
for an unfixed bug, there's no working version to revert to. Imagine the
broken kernel was the one in the release: would you be happy if you had
broken wireless for the entire lifetime of that Fedora release? (And there
were several examples of issues with some hardware in the release kernel
which were fixed by one of the updates.)
Sure, and my wireless was broken in an F8 update and for the initial F9
release and fixed in an update. (Then broken again, and so I was running
an older kernel for a very long time)
gphoto in F9 doesn't work with some canon cameras (and I just looked and
there never was a fixed package pushed to stable, so its still broken in
F9...).
Yes, there is the choice to run an older version, but I'm not sure that
its a good choice. Its hard to downgrade since the updates are pulled,
and there are sometimes flow-on dependancies.
My point is that every update may fix things, but it may also break
things. There's a risk/reward tradeoff that is different for different
packages and maybe there's a sample bias too (ie we only see the
packages that go out when they break stuff, and never have several
hundred post threads about packages that are held back for rawhide).
If we started holding back packages where there is no obvious reason to,
there might be a lot more such threads.
Possibly more threads, but how many people wanted KDE4.1 because it was
the latest available, and how many had a specific bug or feature that
they wanted fixed?
Bradley
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
