Staging and replacement repos?

Hi! Recently in the "Where we are and where do we what to go?" discussion the request for additional dedicated repos for specific needs came up (again) in a sub-thread that ended in this mail: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-February/0... A week weeks earlier there also was the discussion to start a staging repo: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-December/0... I thought it might be wise to start a general discussion about this ideas. == Why do we need it == Basically: to get people to work within the RPM Fusion project instead of creating or maintaining their own repos in various places. That in the end will hopefully shrink the number of 3rd party repos a lot and get people to work together within the RPM Fusion project (and in the end more packages into the main repos), which will likely be better for us, the users and Fedora in general. == What people want == What people want is afaics (correct me if I'm wrong) this: * repos that packages can easily enter without going through lengthy reviews (let call it "staging" or "kitchen sink") * generic and specific repos that contain stable packages that will replace packages from the distribution (Fedora, EL & EPEL) they are build for ("replacements"). * generic and specific repos for experimental stuff that is not yet ready for Fedora's or RPM Fusion's updates, updates-testing, or rawhide repos ("replacements-experimental") === More detailed description and examples === ==== staging"/"kitchen sink ==== A place for packages that the submitter has created, can update them sometimes, but he is not willing to submit them for official review. The reasons can be lack of hardware or time, loss of interest, etc. But the packages exist and everybody is encouraged to grab them, enhance them and officially submit them on his own. It can even be used for packages that are under review already. ==== replacements ==== Repos that hold packages that are considered to risky to ship as a regular updates for Fedora, RHEL or RPM Fusion, but nevertheless are of interest for certain types of users. A example for such a specific replacement repo could be a "kde-redhat" repo which provides the latest stable KDE for the latest releases from Fedora or RHEL. A specific repo only makes sense for popular things like KDE; all the other stuff could go in the general replacements repo. ==== replacements-experimental ==== Repos that act as bed for packages that are not yet ready for Fedora's or RPM Fusion's updates, updates-testing, or rawhide repos, but are designed to land in those repos sooner or later. A example for such a specific repo yet again is "kde-redhat" -- but this time its experimental area, to give KDE users a place to get the latest KDE for testing on rawhide or the latest Fedora release without getting other experimental stuff that is not ready yet. A specific repo only makes sense for popular things like KDE; all the other stuff could go in the general replacements-experimental repo. == Discussion == Do we have enough infrastructure and people that maintain the infrastructure to realize all of the above? Unlikely, that's why we should start small and do one thing after the other. I'd say we should focus on doing kde-redhat and a small staging repo as test beds before we start to do more things. But the directory layout for the repos on the webserver should from the start of leave room for all the others things. How do we handle the keys and who takes care of pushing? A specific key per repo liekly makes most sense. Maintainers of big specific repos (like kde-redhat) maybe should get direct access to the buildsys and the key. That should keep the overall number of people with access to the buildsys and the unsigned results from it small while giving people enough flexibility to do things like removing obsolete packages (which likely will happen often in the replacements-experimental repo). Where do we need splits like "updates" and "updates-testing" and "free" and "nonfree"? Good question -- to many splits like these are likely confusing and more painful then helpful. Thus we should do them only where needed. The replacements repo is afaics the only example where we need the split in "updates" and "updates-testing"; splitting it in "free" and "nonfree" OTOH might not be worth the additional benefit here, thus I'd say (at least right now) we go without it for the start and add such a split later in case it's needed. How to split things in CVS? New roots with names like those mentioned above (staging/replacement/replacement-kde/replacement-experimental/replacement-experimental-kde)? How to avoid conflicts when people mix different repos in interesting ways? We should clearly define which repos depend on which other repos. Conflicts will nevertheless happen. It's left up to the repo maintainers to fix them, hence we should run the repoclosure scripts after each push to make sure people are aware of the problems; sometimes fixing problems might mean to build related Fedora pr RPM Fusion packages from the normal repos in one of the replacement repos to solve conflicts. How to make sure that packaged from the staging repo get reviewed and moved to the proper repos -- if nobody bothers to get their packages reviewed then the staging repos might become out main repos over time? Yes, those are risks the staging repo brings, hence we should try to make people wanting to get their packages into the main repos. Hence we need to keep a close eye on the idea and put safety checks in place to make sure all the important things enter the main repos sooner or later. But the risks are not new -- a lot of private and often small staging repos exist already: http://rpmfusion.org/FedoraThirdPartyRepos Often they are even maintained by Fedora and RPM Fusion contributors. They most of the time know that it's important to get their packages into the main repos, but those packages are not important enough for them to invest the time. How could a directory layout look like? Maybe something like this could do: free/ free/[...] # -> the existing free repo nonfree/ nonfree/[...] # -> the existing nonfree repo staging/ staging/fedora/ staging/fedora/<below here just like in the main {non,}free repo without the releases/ and updates/testing/ subdirectories> # -> the staging repo; only for Fedora, not for EL; do we want a simple layout (like shown above) below staging/fedora/ or one that matches the main repos? replacements/ replacements/{el,fedora}/ # -> the basic dirs for the different replacement repos replacements/{el,fedora}/general/ replacements/{el,fedora}/<below here just like in the main {non,}free repo without the releases/ subdirectory> # -> the general replacements repo replacements/{el,fedora}/kde/ replacements/{el,fedora}/kde/<below here just like in the main {non,}free repo without the releases/ subdirectory> # -> the specific replacements repo for kde-redhat replacements/{el,fedora}/experimental/ # -> the basic dir for the different replacement-experimental repos replacements/{el,fedora}/experimental/general/ replacements/{el,fedora}/experimental/general/<below here just like in the main {non,}free repo without the releases/ and updates/testing/ subdirectories> # -> the replacements-experimental repo replacements/{el,fedora}/experimental/kde/ replacements/{el,fedora}/experimental/kde/<below here just like in the main {non,}free repo without the releases/ and updates/testing/ subdirectories> # -> the specific replacements-experimental repo for kde-redhat EOF Comments? CU knurd