On Wed, Jan 07, 2004 at 01:35:13PM -1000, Warren Togami wrote:
freshrpms/axel/dag/newrpms is comprised of several one-man operations that sometimes conflict and cause package clashes.
Even when that happens from time to time (the compined repos do have 892 packages as I just read off Dag's page), these are far less severe than the painful "Epoch: 0" slamming that fedora.us applied with obvious zero QA, breaking all users mixing repositories.
In fact we should be the ones warning from mixing with fedora.us.
They have no published QA policy and only after-the-fact peer review and revisions.
Well, Red Hat also does not have published QA policies, so this is not a sign of not having QA and good packaging. And fedora.us has been accomodating its QA policy also to its liking, or some people were suddenly dictating package submission freezes and unfreezes as they saw fit.
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.
I am sure you have to believe that ;)
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]
Yes, that is true.
BTW the fedora.us folks are not the problem. I found them mostly cooperative and willing to discuss common problems (but then mostly private). There are very fine packagers among them, and most of them don't believe in monoculture, too. I hope to see a phase transition, or an internal revolution, that will drop the bad hertitage.
(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.
Isn't rpm.livna.org the offspring from fedora.us, where all no-go packages were copied to (rhetorical question ;)? So it isn't a real accomplishment to be cooperative with yourself, as it is not a wonder either that fedora.us has indeed a repository it does not reject cooperation with ...
(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.
So, R P Herrold's workflow suggestions have not only been ignored but totally wiped out of memory, too.
Here is a simplified paragraph of (the known) ATrpms QA procedure: Packages exist in four states: "stable", "good", "testing", "bleeding". New packages enter at the end of the stability scala. People do QA by chosing their stability level. Their feedback decides on moving the package into more stable or less stable regions.
This had been suggested on fedora.us more than half a year ago.
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.
So you won't propose "RepositoryMixingProblems" there? ;)
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.
I think the winnings would have been more on not dublicating things. We could be twice as far, if fedora.us had only invested time in packaging not already packaged packages, or had invested into compatibility, as the free repositories cannot use fedora.us due to its mixing problems (Compatibility issues must ba handled from both sides).