Thorsten Leemhuis wrote: I'd rather see references in our wiki (something similar to http://wiki.centos.org/AdditionalResources/Repositories ) then hosting packages which have not been reviewed.

Andrea Musuruane wrote: Sure, let me rephrase: I would prefer to have a wiki page pointing to other repositories rather than distributing ourselves unverified packages. I have seen way too many packages which do not respect our packaging rules.

Andrea Musuruane wrote: Not at all, it is just fine. I just wanted to say that hosting 3rd party rpms is not a good idea.

2008/12/14 Thorsten Leemhuis <fedora(a)leemhuis.info&gt;: [...] I don't think it is a good idea. If an external (i.e. non RPM Fusion) package maintainer hasn't the time or the will to submit packages for review, I don't think he will have time or will to use our infrastructure. And if this is not true and they will use our infrastructure, they are just one little step away to be part of RPM Fusion (i.e. they only have to submit a package for review). I can be wrong, of course. But the only way to check this is to ask external package maintainer what they think. Regards, Andrea.

2008/12/15 Thorsten Leemhuis <fedora(a)leemhuis.info&gt;: Let me rephrase that. I think that if we convince external repository maintainer to drop their repo and use our infra (IMHO that is 95% of the work), then we could easily convince them to submit their package for review here. Sure, more is needed, I couldn't agree more. We need those 3rd party repo maintainers to join us like we did with the original merger. The real question is what they are going to do. I think we can start inviting them (or inviting them again) on this mailing list and start discussing with them this question. Bye, Andrea.

2008/12/15 Paul Howarth <paul(a)city-fan.org&gt;: Can we separate testing repos in that list? Can those maintainers that have such repos move them in a new section? Regards, Andrea.

David Timms wrote: Very few I suspect though I don't collect stats so I can't be sure. I know there are people using the EL4 and EL5 versions though, as I get the occasional email from them... Upstream actually makes releases of the development version and calls it "bluefish-unstable". It's parallel-installable with bluefish and has varying degrees of stability. I'm able to use it on a regular basis though I don't make extensive use of the feature set. It's basically a means of getting slightly wider exposure for the development tree, which is quite different from the official stable version. Not sure how much usage that would get. BitTorrent 4.x is equally dead upstream but lives on in Fedora. The 4.x version has a pygtk-based GUI that does still work on current releases, which is why 5.x never made it into Fedora. I think there's actually plenty of stuff that's dead upstream but stable and it stays in Fedora whilst people use it. The reason I don't want to maintain the compat-wxPython package is more to do with the maintenance burden being too much for me; if I can't do it justice, it shouldn't be in there. The same would apply to rpmfusion - I don't want to maintain things I can't offer any meaningful support on. Paul.

Nicolas Chauvet wrote: But repo reputation can also be an issue, eg if a user made concerted effort to have the rpmfusion resources build bad packages, that are available (even if not by default) the fallout from bad press would still be felt (rf provides backdoored mediaplayer...) As I understand it, opensuse has a fully public build service, and it's something that rpmfusion could potentially do. There could be some pre-requisites like: - spec must pass rpmlint with no errors nor warning. - home page must exist (200 + content). - builder only retrieves the SourceURLs - hence must currently exist. - must create a rpmfusion fas account I'm thinking here of things that can be tested with automation, rather than needing lots of manual intervention. However, from the security point of view, isn't there a potential for a builder to be vulnerable to bad packages ? And to DOS, unless / even if fas account is required. Also, might need tonnes of extra space (as Fedora itself has trouble with from time to time). Having only limited experience with this I know that with the extra work it takes to get an already working package into Fedora/RPMFusion shape, that once I have that "Package Approved" statement, it's like a sigh of relief. What's in the repo is what has been reviewed, and changes shouldn't be undertaken lightly. If I got green light at first attempt, there would be no incentive for me to continue to work to get the package into tip-top shape, once it is already in the repo. Contrast this with say mozilla development, which seems to occur within bugzilla as patches, that then get reviewed and super-reviewed before the developer is allowed to commit the changes. Instead of -testing, perhaps a better name could be "under-review" or similar to strongly indicate the lack of peer review. I think that having specs / patches in revision control is important because then you can more easily check diffs between last and current fix. It's also a big step for first time packagers with no/little revision control system experience. I like the idea that specs, and patches live in cvs from inception. I've made the effort to package, and then managed to lose my development version in the past. It's the experience of those "proven contributors" that needs to bleed out to us other packagers. I tend to learn / remember more from a suggestion to do X, maybe checkout how reviewer did it with package Y, and actually doing the change myself. If further people don't gain those skills, how can the community be grown ? Another query, do we expect people to actually at least build on their own machine (with either Fedora or EL) before submission ? One way to encourage that is the current review request where you are asked to provide the rpmlint of your locally built .src.rpm and rpm's. I do see a lot of "can I submit this" sort of queries, where the user has found the spec for some other distro, and has no idea what or why that wont be suitable for Fedora/EL + RPM Fusion, has probably never tried to build it. I'm not saying that existing code shouldn't be used/built upon - more that we pride ourselves on quality packages... and this does take some effort to understand the guidelines. DaveT.