When to move updates from testing to stable (was: Re: Move packages from testing to stable repos for F8 and F9)

[Michael Schwendt]

On Thu, 30 Oct 2008 10:12:36 +0100, KH KH wrote:

> 2008/10/29 Thorsten Leemhuis:
> 
> >> The push scripts by default push everything to testing. That is IMHO a
> >> good thing to do as default. But when to move packages to the proper repos?
> >> Simply one week later by default? That would not be that hard to do afaics.
> If the push script default everything to testing, but on the others
> side it lack support for pushing packages to stable.

That's misinformation.

The short story: The pushscripts can release pkgs to stable directly.

The long story: Historically, Plague and the pkg cvs Makefiles for Fedora
Extras were set up in a way we had only a single build target per branch
and no scratch-builds either. We couldn't choose between building packages
for "stable" or "testing". And neither we could choose between building
"against stable" repos or "against testing" repos. All builds for a branch
used the same set of repos for the buildroot and ended up in the single
"needsign" (aka plague-results) repo. From there the pushscripts copy
packages into the target repositories. No tag or other meta information
created by the buildsys or the buildsys user tells the pushscripts whether
to release something in "stable" or in "testing". To make "testing" repos
for EPEL possible, the pushscripts were modified to push to "testing"
by default and offer a way to either move pkgs from testing to stable
or to skip testing. The latter option can push builds from needsign
directly into the stable repos.

> The result is:
> more human admin tasks.

Yes, unfortunately. It has never been the plan to stick with the scripts
for such a long time, especially not after the first rumours about a
replacement for Plague (which is also why Plague development had stalled
silently). At the beginning, only a much shorter, severely limited and
fragile set of scripts (Bash+Python) was available, which broke in new and
funky ways almost with every push of packages (and repairing damaged repos
is no fun). The pure Python based pushscripts are the result of getting
rid of Bash, making them stable for a group of signers, and making added
support for build reports, repoview, repoprune and friends painless. Quite
a lot of code in the pushscripts is bloat (like working around file
permission bugs in python urlgrabber to make shared Yum mdcache dirs
possible).

Now that koji+bodhi are available, a separate web-based updates system for
Plague (or a further developed Plague) would need to copy lots of
features, (e.g. inheritance, tagging, chain-builds) or else it would be
different enough to confuse packagers. EPEL is such an example, where
Fedora packagers just don't want to accept that different tools are used.
And if the updates-system were not web-based, but command-line driven,
it would be bodhi-client there and some other client here.

> For example, I want the vlc built in F-9 to be
> pushed to stable right now. how should I do ?

If it's still in needsign, those who push can do it:

    PushPackage.py
    Usage: %s <project> <release> <name> [--stable]

$ ./PushPackage.py RPMFusion_Fedora_free 9 vlc --stable

will skip updates-testing (and edit the build report appropriately, too).
 
> Now another case: vlc in F-8 will stay with 0.8.7, because the
> behaviour will change too much and my grand-mother (that use Fedora
> 8). will be disappointed.Now, I don't want to discuss why it is needed
> like this, here.
> But what is needed actually is a way to "also" propose an update to
> 0.9.x. Can I handle that with the rpmfusion-free-updates-testing
> repository ? It will lead to have two parallels cvs (F-8 F-8.testing
> like it was with livna), because it should remains possible to update
> the two versions.

That's where Plague and the pkg cvs setup would need to be modified a lot
to support a _separate_ (!) target for test packages. Currently, your
0.9.x builds would become available in the single buildroot and hide the
older 0.8.7 release.