Eric S. Raymond wrote:
These both seem like readily solvable problems to me.
If you look at http://dag.wieers.com/home-made/apt/mega-merge.php, you'll see that this group describes itself as "The Red Hat/Fedora authoritative packager list". That sure sounds to me as though they would welcome official status if offered.
fedora.us is a collaborative project with about two dozen active packagers involved every day. freshrpms/axel/dag/newrpms is comprised of several one-man operations that sometimes conflict and cause package clashes. They have no published QA policy and only after-the-fact peer review and revisions.
http://www.fedora.us/wiki/RepositoryMixingProblems Due to these reasons fedora.us has always said that we will not coordinate with external repositories. We never have these package clashes, and our package quality is on the average better. The drawback here is slower package review and publication.
Those other repositories are authoritative, within their own world. You can choose to live in either their world, or our world. Open Source means you have the freedom to choose. I choose to live in the fedora.us world, and apparently so did Red Hat. [1]
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
It already seems to have happened. It seems that rpm.livna.org is collaborative with a Bugzilla and QA procedure too.
(2) RPMs must meet Fedora QA standards. Repository maintainers must expect their submission, test and build procedures to be audited, and will be dropped from the list of authoritative repositories if they fail to meet standards.
We have fedora.us QA standards and nobody else has suggested a full proposal for an alternative, so currently fedora.us is on track for eventally become Fedora Extras around FC2 timeframe.
fedora.us is the only authoritative repository & project.
There is no authoritative list of repositories because fedora.redhat.com is designed so the user can choose to use any 3rd party repository.
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
We respectfully disagree with this line of thinking.
Warren Togami warren@togami.com
[1] http://www.newsforge.com/software/03/10/01/1417208.shtml