On Sun, Oct 26, 2008 at 7:59 AM, Thorsten Leemhuis <fedora(a)leemhuis.info&gt;wrote: Any sdlmame package that is in the testing repo should not be moved to updates.

On 26.10.2008 23:55, Julian Sikorski wrote: Anything else that should not be moved? Which BTW brings us to the question: how do we want to handle "testing" in the future. 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. Please note the "default" in above para. There are a lot of cases where doing it differently makes sense; just two of them - if the maintainer has good reasons for moving a package more quickly or more slowly - if there are interdeps with Fedora packages that packages will get pushed or moved to the proper repos in sync if possible. CU knurd

2008/10/29 Thorsten Leemhuis <fedora(a)leemhuis.info&gt;: Yep and I remember to have asked the same question worded like this: Do updates-testing behaviours ends to be like it was with livna or with fedora? If the push script default everything to testing, but on the others side it lack support for pushing packages to stable. The result is: more human admin tasks. For example, I want the vlc built in F-9 to be pushed to stable right now. how should I do ? 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. If not possible, then I will stay with 0.8.7 in rpmfusion for F-8 and provides the 0.9.x in my personal repository. (But that's not the way it like it to be used). Nicolas (kwizart)

Thorsten Leemhuis wrote: +1 Regards, Hans

On Thu, 30 Oct 2008 11:48:16 +0100, KH KH wrote: 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.

On Thu, 30 Oct 2008, KH KH wrote: That's great to hear. What exactly are serious regressions? Not installable? We have rpmfusion-devel as well. What's preventing our developers of doing their regression tests there? Reading that mail, you're retroactively trying to widen the scope of rpmfusion. This was not part of the general idea of rpmfusion. You're advocating _MASSIVE_ investments in manpower which I'm _STRONGLY_ against. We're already quite busy putting rpmfusion as is in place for the F10 release, there's no need to burden people with a questionable repository just to nail down some bugs... Please do remember that we're an add-on repository tracking fedora and following most of the fedora policies. If it breaks in fedora, tough luck, that's what happens when you're following bleeding edge software. Same goes for rpmfusion. The EL repository is another issue. We should take reasonable care of stability but if it's too hard to do because of certain security issues, just update vlc to 0.9 and be done with it. VLC is not a library, it's a frikkin mediaplayer, the impact should be neglible. strong -1 regards, andreas

2008/10/30 Michael Schwendt <mschwendt(a)gmail.com&gt;: This wording sounds like mixing the discution and decision, as nobody here wants to fork. At least a more correct wording would be "extending capabilities." But I can understand that somehow, having a replacement packages repository for some special cases still reminds bad times for certains old ears. Thx for this, this is the first rational argument I've received from the list about the subject. Now that's totally possible not to have this repository, but we should be aware that some case thus cannot be supported within rpmfusion. That will be a repository design problem . (example the nvidia beta drivers at least for legacies, but there are others cases). Nicolas (kwizart)

On Thu, 30 Oct 2008 10:12:36 +0100, KH KH wrote: 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. 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. 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). 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.

2008/10/29 Thorsten Leemhuis <fedora(a)leemhuis.info&gt;: I think that we should first understand how packages go from testing to stable. Who controls the process? How can a package maintainer choose to issue a release to stable in a faster way (e.g. a security update)? How can a package maintainer choose not to issue a release to stable (e.g. a beta release)? IIRC we should follow Fedora as closely as possible. But again I think that having that infrastructure in place won't be an easy task. Bye, Andrea.

On Thu, 30 Oct 2008 11:00:49 +0100, Thorsten Leemhuis wrote: More important than that is the locking between the Plague master and the pushscripts, so the needsign repodata is never modified while Plague is working on it. Plague doesn't contain any code to clean up the needsign repo itself. It would grow and grow, and using plague-client to mark packages as "finished" doesn't do anything useful either. ;) If the original flock-based locks really cause a deadlock with nfs, my changes in Plague cvs have added optional POSIX locks, and they can also be enabled for the pushscripts.