When to move updates from testing to stable

[Michael Schwendt]

On Thu, 30 Oct 2008 11:48:16 +0100, KH KH wrote:

> I don't mind the technical behind this., was about the behaviour.
> If i cannot get that behaviour with having two parallels branches,
> then that's easy, there will be no vlc-0.9.x updates for F-8
> That's not that important in that case but others case are.
> 
> btw we have new beta legacies drivers (71xx 96xx), the fun is that
> suches parallele cvs repositories are needed for testing version from
> the same series. (along with building kmod for the stable version).
> 
> Now, no matters is that live in a different cvs, with a different mock
> config and a different repository.
> For now i will handle that in my personal one (kwizart-testing), but
> again, it rpmfusion will miss to handle that cases.

Reminds me of an old discussion and the following conclusion.

First you create a separate build-target for test-updates to be published
in updates-testing. Then, when you build a test-upgrade (e.g. vlc 0.9.x),
you find that you no longer can use updates-testing for test-updates for
the stable branch. 

You would need another stable-updates-testing repo. ;) Or you would need
to withdraw the experimental test-upgrade, then build the test-update for
stable, and then find that any rebuilt deps in updates-testing now suffer
from breakage.

As a work-around (and because you can't pull all test-upgrades and
test-rebuilds as users may have installed them already), you publish the
test-update for stable directly in the stable repo. Be prepared to be
flamed by your precious users in case this rushed stable update breaks
something. You also notice that any packager with a dependency on your
experimental test-upgrade can no longer use updates-testing for normal
test-updates for "stable" either.

With koji you cannot do such test-upgrades either without getting releng to
tag for buildroot-override or without pushing upgrades to "stable" first.
Same issues (except that it's possible).

Rule of thumb: Use development for the somewhat experimental stuff as long
as the freeze is far away. The more dependencies, the higher the risk for
major version upgrades in "stable". They are not worth the trouble.
Updates-testing is not popular anyway.