On Wed, 30 Jun 2004 14:58:56 +0200, Rudi Chiarito wrote: > I was just hoping to simply kill the repository > once Fedora had a streamlined submission process, but that's apparently > still in progress. And no one discusses any details, so it is not known what you would like the "streamlined submission process" to look like. The current package submission procedure is focused on testing packages prior to release and prior to submitting them to the non-automated build system. Packagers might find that filling in bugzilla forms is an extra burden. Some might want to upload their packages into an /incoming FTP directory and be done. But actually, too many submitted packages either fail to build or contain bugs which ought to be corrected prior to first release. Effectively, new packages need to be reviewed or else the build team would be overloaded with failed build attempts (there is no automated build system yet) or many package bugs would enter the repository. At fedora.us, further QA policy changes are in the queue. One which allows for new packages to enter the "unstable" repository after a very basic review (in particular the security relevant checks) and then hope that the community reports any missing flaws. But even then, the packagers ought to make sure their packages build at least on all the target platforms and adhere to the packaging guidelines, too. The packagers themselves should do a good portion of the QA for their packages. For instance, there is documentation on how to use 'fedora-rmdevelrpms' or 'mach' to find missing build dependencies. And there are several other packaging topics covered in the Wiki, too. The most time consuming parts of the current submission process are when * a package doesn't build (a review stops here unless the reviewers does the packager's work and completes build requirements or develops fixes) * a packager doesn't reply to bugzilla comments for a long time (either because he's entirely occupied with other stuff or has lost interest or has a different point of view than the reviewer / even a status update would be nice) * basic functionality testing and reviewing of package contents raises a few questions (e.g. disabled features, files in questionable locations), but the answers take a long time / the reviewers move on, look into other packages, and see how unfinished packages in their queue piles up * packagers don't improve the submitted and reviewed package, but return with a major version upgrade and completely rewritten and reformatted spec files (a diff is useless!) * the packager doesn't seem to do the final step of the submission process--the verification of the binary packages--and probably expects QA people to do that, too, without saying a word
