audacity-nonfree, normalize: ? maintainership ?

[Thorsten Leemhuis]

On 13.08.2008 02:16, Michael Schwendt wrote:
> On Wed, 13 Aug 2008 08:25:12 +1000, David Timms wrote:
 > [...]
>> I don't remember seeing any similar -testing repo for livna, rpmfusion 
>> {other than devel, which I expect is for use with fedora-rawhide}, have 
>> I missed that ?
> -testing at rpmfusion seems to be different from livna/epel style. That
> is, there is now a new set of repos: releases, updates, updates/testing,
> and development.

I'd say it quite similar to epel style. It's just that the plan is to 
have a additionally release repo (for spins and to use in anaconda 
during install if you don't enable the updates repo). But those are 
afaics outside the scope of the push scripts; my plan is to simply 
create them with something like this

$ cp -l developemnt/<arch>/ releases/10/Everything/<arch>/os/

and maybe a few other commands.

> Builds are put into "updates/testing" first and
> moved to updates after some time.

Just like in EPEL, yes. But I'd say we'll have more relaxed rules and 
will do those moves way more often then once a month. And I'd assume 
that pushing directly to stable will happen more then just "now and then".

> Whether it is built against
> fedora updates-testing, I don't know. I have doubts that it is done.

I've thought about it and for the start chose to not include 
updates-testing in the builders mock configs. Chances are IMHO way to 
big to build against a Fedora updates-testings package and then pushing 
the RPM Fusion package to stable before the Fedora testing update it was 
build against hits Fedora stable.

But we of course can enable updates-testing quickly if we want to.

> Theoretically, Plague can be set up to do real updates-testing builds.
> [It can also do scratch builds, btw]. In both cases, however, additional
> build targets are needed, so the build slaves pull in the updates-testing
> repos. It would require more modifications, e.g. in the pushscripts (a new
> method to move pkgs between repos) and something like "make build-testing"
> or similar. It would be quite clumsy. [...]

Agreed. It's likely a lot of work that is not worth the trouble. 
Especially as the packagers would need to put a lot of effort and 
thoughts into their work to not break things accidentally...

CU
knurd