RPM submission procedure

[Axel Thimm]

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).
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040108/490185c6/attachment-0002.bin