Adam Williamson wrote:
> and Mandriva certainly wouldn't consider shipping KDE 4.2 as a
> 'stable' update for KDE 4.1. Neither would Ubuntu. You can *get* KDE 4.2
> for both Mandriva and Ubuntu releases that shipped with KDE 4.1, but
> it's not released as a stable update, nor - IMO - should it be, *in a
> distribution which uses stable updates* (which, right now, Fedora
> isn't).
The feedback we got for the 4.2 updates was almost 100% positive, we got
thanked a lot for finally shipping a "usable" KDE. Now I disagree with the
claim that 4.1 was not usable, but several users felt the 4.2 update was
needed for it to be usable for them.
> I don't think that follows at all. Updates policies, above all else,
> need to be consistent, and if you say "well, we'll try to be quite
> stable and safe, but ultimately it's up to the discretion of
> maintainers", you will never get consistency, because all maintainers
> are different. What Maintainer A considers a 'safe' upgrade will be
> different to what Maintainer B considers safe. Hence the user experience
> will be inconsistent. Effectively, the update process will only be as
> safe as the most happy-go-lucky maintainer's position - even though all
> other maintainers are more conservative. And that's not efficient,
> because you get all the drawbacks of instability from the maintainers
> who push whatever they like, and all the drawbacks of staleness from the
> maintainers who act very conservatively.
It's true that inconsistency is bad, and that's the problem with the current
policy, but there's no better solution. At best, we can give more hints to
the maintainers, but there's no policy which works for all packages.
Hardcoded bureaucracy doesn't really work, in particular, the 2 "all or
nothing" solutions you propose:
> This is why I say the only two policies that can really work optimally
> are "minimal necessary changes to fix strictly identified bugs and
> security flaws" or "update whatever you like". Either is valid, but both
> have distinct implications for the user experience, so we need to pick
> based on what user experience we want, and message that consistently so
> that users know what to expect.
are both completely broken. The first turns Fedora into yet another "Debian
stable type" distribution: this seems to be what you're advocating, but
there are already several of those and Fedora would lose one of the main
things it is about (being always up to date) by endorsing such a policy.
The second basically turns all releases into Rawhide, which is
unfortunately unsuitable for daily use. A middle ground is needed, and
that's where the maintainer has to make a call. And this is why the policy
is as it is now.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
