how to make things better(tm)

Kevin Kofler kevin.kofler at chello.at
Fri Mar 5 18:56:19 UTC 2010


Bill Nottingham wrote:
> If we are going down the road of providing absolute-latest-versions on
> older releases, perhaps not pushing it to prior releases until it's
> actually been in wide use on the next release? So, you have, for example:
> 
> - new version 4.6
> -> push it to rawhide, get testing
> -> get new Fedora release with that version
> --> get *even more testing*, make needed fixes
> 
> And only *then* do you push it to the prior releases, once it's actually
> proven that it's not going to break things for the widest group of users.
> It lets you not only use the rawhide adopters, who expect major change,
> but the next-release early adopters, who also expect adjustments on moving
> to a next major release.

The problem is that this translates to a LOT more work for us. By pushing to 
both releases at the same time, we can build things together, do the 
buildroot overrides together, queue things to testing together, promote them 
to stable together. Doing things in the staged way would mean almost twice 
the workload (especially in terms of time expense) for us. :-(

In addition, we already got 4.4.0 out only barely before 4.4.1 was released. 
If we had staged it as you propose, we'd now be stuck with having to do one 
of 2 things:
A. push 4.4.0 into F11 and 4.4.1 into F12. This means:
- we'd be working on 2 different releases at the same time, which would 
stretch our resources quite a lot,
- F11 would end up with a KDE "update" which is already obsolete when 
pushed, and in particular includes known bugs which are fixed in the bugfix 
release that 4.4.1 is.
B. skip 4.4.0 in F11 and go straight to 4.4.1. This means:
- we'd be shipping the same release, but in one case as a big update with 
many other related packages to update, and in another case as a bugfix 
release. This also means 2 very different updates to prepare at the same 
time and would also stretch our resources quite thin.
- the F11 update would either not be staged compared to the F12 4.4.1 one, 
or the wait for 4.4 would be even longer than a month.

Support would also get more complicated with the 2 current versions in 
circulation simultaneously. Right now, if something's fixed in F12, it's 
also fixed in F11 and vice-versa, and we can in general expect our users to 
all run the same KDE (unless they just haven't updated yet).

And finally, those F11 users who want 4.4 would feel treated like second-
class citizens for having to wait longer, those who don't want it just don't 
want it at all, staged or not.

So I don't think staged updates are a workable solution (there's a reason 
almost no maintainer works that way at this time).

        Kevin Kofler



More information about the devel mailing list