What Fedora makes sucking for me - or why I am NOT Fedora

[Kevin Kofler]

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.

> Excluding support for new hardware, if you want a bleeding edge feature
> run rawhide. 

If you want a conservative distro, run CentOS.

>> Also because you'll then also get those major changes which were
>> intentionally not pushed as updates to that release, e.g. KDE 4 for
>> Fedora 9, kdepim 4, Amarok 2, digiKam 0.10 and Krusader 2 for Fedora 10,
>> probably KOffice 2 for Fedora 11.
> 
> So you want the latest and greatest new version, as long as its not too
> new?

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.
(Those are the criteria for applications, for libraries there's of course
also: the soname either stays the same or all the dependent packages get
rebuilt. Updates which break dependencies are a no-go.)

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.

Major rewrites should only go into new Fedora releases, but I don't see "add
feature X" type upgrades as a problem.

> There's a difference between pushing new versions that fix bugs, and
> pushing them the day after an upstream release to stable and rawhide
> simultaneously, with a comment of 'new version'.

Well, I agree with you on this point:
* Updates should contain a description of:
- what's new (a link to the upstream changelog will do, or the maintainer
can sum up the changes him/herself) and
- where not immediately obvious ("This bugfix release was pushed to fix the
bugs in the previous release.", duh), why the update is being pushed
(e.g. "new version of libfoo needed for the latest bugfix version of bar").
* If the update fixes a bug filed in Fedora, the Bugzilla reference should
be present.
* Non-critical, non-trivial updates (and in most cases version upgrades are
neither critical nor trivial, but there are exceptions) should stay in
updates-testing for at least a week.

I'm completely OK with enforcing the above rules (though it should be the
maintainer's call to decide what's critical or trivial, so I don't think
that particular rule can be enforced, it should just be made clear to the
maintainers; descriptive update comments _are_ enforceable though), but
they are a very far cry from banning version updates entirely!

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

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.)

> 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. I remember the "Where is KDE 3.5?"
thread in the FC4 times, just because Than didn't push out the upgrade
right away (he eventually did). There were also plenty of "Where is KDE
4.1?" threads when the update was delayed first because we found some
issues during testing which we had to fix (because in KDE SIG we *don't*
push out known-broken updates!) and then because of the infrastructure
breakdown due to the intrusion.

        Kevin Kofler